Nullcon's Berlin edition continues to punch above its weight. The conference has grown steadily into one of Europe's most technically serious security events, and its 2026 program reflected the continent's particular set of concerns — Cyber Resilience Act readiness, sovereignty-driven open-source investment, and a research community with distinct priorities from its US counterpart.
For supply chain defenders, Nullcon Berlin 2026 was a high-signal week. The sessions skewed technical, the audience was dense with practitioners from regulated industries, and the hallway conversations were uncommonly pragmatic. Here is the analyst view of what mattered.
How is the European supply chain conversation different from the US one?
It is shaped by regulation in a way the US conversation is not. The Cyber Resilience Act's reach into the software and hardware that European organizations ship and consume has given the technical community a shared reference point that anchors almost every supply chain discussion.
At Nullcon, this showed up in concrete ways. Speakers framed research findings in terms of what they would mean for CRA compliance. Vendors at the small but technical sponsor area positioned their tooling in terms of whether it helped produce the artifacts — SBOMs, vulnerability disclosures, attestations — that the regulation expects. Attendees from manufacturing and industrial sectors in particular came with implementation questions rather than abstract ones.
The second big difference is the sovereignty thread. European practitioners are thinking hard about dependencies on US-origin tooling, cloud infrastructure, and open-source ecosystems that concentrate in the US tech sector. Several hallway conversations touched on the practical implications of that concentration for supply chain risk — not in a political way, but in a resilience-planning way. What does your program look like if a dependency you assumed would always be available becomes restricted, embargoed, or operationally unreliable?
The third is the open-source funding conversation. European programs like the Sovereign Tech Fund have given the region a distinctive approach to the maintainer sustainability problem — direct public investment in critical open-source infrastructure. This is increasingly treated as a supply chain control, not just a policy program.
Which technical sessions produced the most defender value?
The research-oriented Nullcon tracks delivered a batch of sessions that practitioners should track down in recordings when they publish.
Sessions on package ecosystem attacks continued the trend of finding novel exploitation primitives in ecosystems beyond the most famous registries. European researchers spent time looking at the Debian and Ubuntu package ecosystems, OpenWrt and Yocto for embedded systems, and the various artifact registries used in industrial software. The findings reinforced a consistent theme: the less-examined an ecosystem is, the more ground-floor attack surface it has.
Sessions on build pipeline attacks focused less on hyperscale CI/CD providers and more on the self-hosted and on-premises CI environments common in European industrial software. The threat models are different — fewer multi-tenancy concerns, more concerns about physical access, long-running build infrastructure, and the implicit trust that accumulates in servers that have been running the same Jenkins instance since 2019.
Sessions on firmware and embedded supply chain were especially strong. This is an area where European research traditionally leads, given the concentration of industrial, automotive, and IoT manufacturers in the region. Several talks walked through realistic compromise scenarios in firmware build and update pipelines, and the implications for CRA's security-by-design requirements.
What did CRA readiness sessions reveal about industry progress?
That it is happening, unevenly, and with more operational pain than vendors are advertising.
The sessions at Nullcon that dealt with CRA implementation tended to feature practitioners from companies that have been actively working through the regulation's requirements for months. Their observations were refreshingly direct. SBOM generation is largely a solved problem for modern greenfield codebases. It is substantially harder for legacy products, embedded software, and software composed of binary third-party components without accompanying manifests.
Vulnerability handling — the CRA's requirement that vendors handle vulnerabilities in their products, including downstream notification — is a workflow problem, not a technical one. Most organizations have the tooling to identify vulnerabilities in their products; few have the processes to notify downstream customers at scale, especially when those customers are themselves suppliers to their own customers. The operational model this implies is substantially different from how most software vendors currently handle vulnerabilities, and several speakers noted that they were still working through it.
The sovereignty dimension of CRA compliance also came up. For European organizations that rely heavily on non-European open-source projects, part of CRA readiness is figuring out how to substantively demonstrate vulnerability management for components where they do not control the upstream maintenance. The answer usually involves a combination of active engagement with the upstream project, maintenance of internal forks for critical components, and — for a growing list of high-priority dependencies — direct participation in the funding ecosystem through programs like the Sovereign Tech Fund.
How did the research community discuss open-source trust?
With more nuance than the US conversation typically allows. European researchers, practitioners, and funders have been iterating on the "who do we trust in open source and why" question for a while, and Nullcon's sessions reflected that accumulated thinking.
The specific distinctions that came up repeatedly: trust in the maintainer versus trust in the project versus trust in the release artifact. Most supply chain tooling conflates these — a trusted maintainer ships a trusted project and therefore a trusted artifact — but in practice each can fail independently. A trustworthy maintainer can have their account compromised. A historically trustworthy project can lose its primary maintainer and drift. A legitimate maintainer and project can produce an artifact that was tampered with during build or distribution.
Several sessions explored what it would look like to verify each of these trust links independently. The answers that came up were familiar — multi-factor maintainer identity, reproducible builds, provenance attestation, mirror verification — but the framing was sharper. Supply chain security is less about a single silver-bullet control and more about ensuring that each link in the trust chain is independently verified.
This is the kind of conceptual clarity that tends to precede durable operational progress. The tools exist. The remaining work is putting them together into a program that makes the trust chain visible, verifiable, and managed.
What vendor and tooling trends stood out?
Fewer booths than a US megashow, but more focused conversations. The Nullcon sponsor floor tends to include tooling vendors with a strong European presence and, increasingly, open-source project maintainers looking for commercial adoption partners.
The specific trend that stood out was the continued convergence of SBOM tooling, provenance attestation, and vulnerability management into single workflows. Vendors that used to sell SBOM generation alone now bundle consumption and policy. Vendors that used to sell SCA alone now bundle SBOM production and VEX handling. This matches what was visible at RSA, but in a European context the emphasis is different — the tooling is being evaluated primarily against regulatory requirements, not just against security outcomes.
The second trend was the maturation of tooling for embedded and industrial contexts. Generic SBOM generators do not handle firmware well, and generic scanners do not understand the threat models of industrial software. Several vendors and open-source projects at Nullcon have filled that gap with ecosystem-specific tooling, and the audience response suggested there is significant pent-up demand.
What should practitioners take back from Berlin?
Three priorities for the next quarter. First, treat CRA-style compliance as a forcing function for operational maturity, not as a separate workstream. The artifacts the regulation requires — SBOMs, VEX, vulnerability-handling processes — are the same artifacts a mature security program already needs. Building them to satisfy auditors is fine; building them to serve both auditors and operations is better.
Second, extend supply chain thinking into the parts of the stack where it has historically been weakest. Firmware, embedded software, legacy binary components, and self-hosted build infrastructure all have the same class of risks as modern package managers, but with less mature tooling to address them. Nullcon's research community is actively closing that gap, and practitioners should track the work.
Third, invest in trust-chain verification as a concept. Rather than asking "do we trust this component," ask "have we independently verified each of the links that make up that trust." The organizations that structure their supply chain programs around this question are the ones that will stay ahead of the maturing threat landscape.
How Safeguard.sh Helps
Safeguard.sh is designed to operationalize the themes that defined Nullcon Berlin 2026. Our platform produces and ingests SBOMs and VEX documents in the formats European regulators are converging on, making CRA-aligned artifacts a byproduct of ordinary operations. Our provenance verification independently checks each link in the trust chain — maintainer identity, build pipeline, artifact signatures — rather than collapsing them into a single inherited trust decision. And our coverage extends beyond the most famous package ecosystems into the less-examined ones European research has been probing, including container images, firmware components, and the artifact registries used in industrial software. For defenders working in the European regulatory and research environment, Safeguard.sh is built to meet you where the work actually is.