10 insights from MRMCD 2026’s most viewed talks

Enno Lenze’s drone teardown account is as much about making observations usable as it is about opening equipment. His team sorts components, photographs them, reads markings and asks people with the relevant expertise. A photograph with a scale can give another researcher a question they can actually answer.

That matters because Lenze repeatedly reaches the edge of his own knowledge. AI-assisted identification offers a starting point, while specialists do the deeper work. He also says Ukrainian experts generally already know these findings; his team’s distinctive contribution is public documentation. The lesson is a collaborative evidence trail, with uncertainty still visible.

Manuel Atug’s critique of Palantir begins with an ontology: objects, attributes and relationships that join people, devices, locations and interactions. In his account, engineers structure the inputs and build workflows around them; an AI model is one component of that larger arrangement.

He argues that the consequential questions concern how those connections become recommendations and actions, and how difficult it can be to replace the surrounding system. An editorial takeaway from his argument is to examine the data, decision process and vendor dependence together. These are Atug’s interpretations of the systems he discusses, grounded here in his recorded critique.

The Berlin incident session makes a sharp distinction between a written rule and a working control. It describes a prohibition on storing plaintext passwords alongside allegedly exposed password lists, then asks what enforced the rule in practice. The same critique reaches logging, detection and legacy applications that constrain recovery.

The broader argument is about resilience: preventing an incident where possible, detecting it and reducing its consequences when it occurs. The session also advocates a regularly updated, timestamped public incident FAQ. Read this as the recording’s assessment of Berlin; its useful operational question is whether policies, systems and response processes can be demonstrated working together.

The Eurobox talk gives interoperability a wonderfully physical test. Boxes can share familiar dimensions while differing in bottom depth, handles, wall taper, lids and the points where a shelf supports them. A nominally suitable rack can still fail to hold the combination someone actually bought.

The presenter follows those differences through manufacturing, historical research and practical examples. His investigation raises questions about what the Euronorm label guarantees, rather than treating the name as a complete specification. It is a maker and logistics lesson with a clear application: check the interfaces that touch, and measure the space the object will really occupy.

Enno Lenze recounts a journalist turning a supplied security USB stick into ordinary storage after finding that plugging it in did not do what they expected. Another example concerns a secure system that lacked the recipient’s familiar applications. The intended protection and the actual user experience had separated.

His observations come from his own work, chiefly in Ukraine, where people still have ordinary tasks and established habits amid extraordinary conditions. For designers, the editorial lesson is to investigate that context before proposing a setup. A tool needs an understandable purpose, a workable routine and a fit with the person’s actual risks.

A bicycle-oriented traffic-light receiver sounds like a simple countdown project. The recording shows why it is harder: the receiver must identify the relevant intersection, lane and signal group, then interpret the timing data supplied for that movement.

When available, those data can include earliest, latest and likely switching times. Traffic-dependent lights may extend a phase, and some intersections in the presenter’s examples supply only the current state. A tidy number can therefore hide missing information or a changing estimate. The prototype’s unfinished mapping and display work is part of the story. Its useful design lesson is to preserve the source’s limits when turning machine data into an interface.

The MeshCore session with Christian Stankowic shows why hearing a radio signal is only a starting point. Its mapping example distinguishes an acknowledged exchange from overheard traffic, a discovery response and no response at all. Each observation says something different about whether communication works at that location.

The presenters connect those measurements with repeater placement, route visibility and local participation. They also discuss stale map information and devices that are switched off. The practical insight is to test the path a message needs, including the return confirmation, while keeping the network’s limits in view. A promising range figure alone does not describe that path.

The password session becomes especially revealing when it leaves textbook methods and follows real login flows. The presenter recounts adding a security key to an account, then finding that later sign-ins still requested an email token. Another example involves a password shortened during registration but handled differently at login.

He also explicitly says email-token login is not inherently bad; his concerns include choice, dependencies and what the account actually asks for. The lesson from these reported experiences is to inspect the whole journey: setup, subsequent sign-in, device changes and recovery. A configured option is useful evidence only alongside the behavior it produces.

Petri Krohn’s mining-GPU account separates two causes of limited capability. Some restrictions are imposed by firmware; others are tied to physical fuses. He describes comparing variants and an engineering-sample experiment in which changing firmware altered exposed compute and memory.

That distinction gives the research a method: establish which layer is responsible before deciding what can be recovered. Successive implementations then expose different capabilities and reset constraints. Krohn also recounts a clean-room reimplementation based on public material. The insight is careful boundary mapping, rather than a promise that every card becomes an unrestricted A100. The remaining hardware limits still matter.

The QEMU session starts with a small working virtual machine and gradually makes its surrounding responsibilities visible. Running it under a service manager keeps it alive after the initiating SSH session ends. But the first stop operation simply terminates QEMU, leaving the guest abruptly cut off.

The presenter then adds a guest power-down request through QEMU’s monitor and waits for completion. Console access and networking require their own decisions too. The example makes shutdown a separate requirement from process exit. Its author repeatedly warns that these are compact teaching demonstrations, with performance and security work left out. That boundary is useful: understand the lifecycle before treating a successful boot as a finished setup.