CRA, NIS2 and DORA for Engineers: You Can’t Report What You Can’t See

The Blast Radius runs on one conviction: prefer enforcing controls you can verify over promises you have to trust. Real security lives in invariants, the properties that hold against the worst case an adversary can construct, not in averages, vendor accuracy stats, or a model behaving itself. Design it in, make it deterministic, and measure it. This issue turns that lens on Europe’s new security regulation, and on the deterministic inventory it quietly demands.

TL;DR

• These are three broad regimes, not three supply-chain rules. The CRA is a full product-security lifecycle, NIS2 is ten organisational measures plus board liability, DORA is five resilience pillars plus direct EU oversight of critical ICT providers. Supply chain is one thread, not the whole.
• The one engineering thread that ties them together: know what you actually ship, know which components are vulnerable, and be able to report fast.
• The catch: the SBOM they lean on is shallow by law (the CRA floor is top-level dependencies only) and is not required to reflect what actually shipped. A fully compliant SBOM can be silent about, or wrong about, your real contents.
• Wrong depth and wrong order: the 24-hour reporting duty starts September 2026; the SBOM meant to answer it is not mandated until December 2027.
• No regime (CRA, NIS2, DORA, FedRAMP 20x) mandates a SLSA level. They want demonstrable integrity; the level is your risk decision.

Three pieces of European cybersecurity law are simultaneously affecting the engineering profession, and most of the material I find targets lawyers and compliance officers. This post is coming from an engineering perspective. I want to translate the Cyber Resilience Act (CRA), the NIS2 Directive and the Digital Operational Resilience Act (DORA) into what they actually require of your pipeline, your codebase and your dependency graph.

I’m an engineer, not a lawyer, so consult a lawyer if you want legal advice. I’ve looked at these dependency graphs enough to know all three regulations lead to the same engineering challenge, one which I’ve kept prattling on about.

One Theme Connects All Three

You cannot report a vulnerability in a component you did not know you were shipping.

Remember CRA, NIS2 and DORA all follow that same line of thought, which is why software composition is just being window-dressed in a compliance costume.

CRA: Security as a Property of the Product

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the product-security one. If you place a “product with digital elements” on the EU market, it applies to you, wherever you are headquartered. It entered into force on 10 December 2024 and lands in stages. That includes any SaaS or backend components for deployable apps.

Here is the timeline that matters, and the first date is closer than people think:

• 11 September 2026: vulnerability and incident reporting obligations begin. If a vulnerability in your product is being actively exploited, you have 24 hours to file an early warning, 72 hours for a fuller notification, and 14 days after a fix is available for the final report (one month for severe incidents). Reports go through the ENISA Single Reporting Platform. Critically, this applies to products already on the market, including ones you shipped years ago.

• 11 December 2027: the full obligations apply. Secure-by-design, a machine-readable Software Bill of Materials (SBOM), a documented vulnerability-management process, security updates across the support period, conformity assessment, and CE marking.

Non-compliance tops out at 15 million euros or 2.5% of global annual turnover, whichever is higher.

But the reporting clock is only the thin edge of the wedge. The bulk of the CRA is a full product-security lifecycle obligation, the S-SDLC, and the essential requirements in Annex I read like a secure-development checklist: ship with a secure-by-default configuration, carry no known exploitable vulnerabilities at release, protect the confidentiality and integrity of data (including through encryption), minimise the attack surface, enforce access control, resist denial of service, and let users securely remove their data on decommissioning. On top of that come security updates across the product’s defined support period, which for many products is expected to run at least five years, plus conformity assessment and CE marking (most products self-assess, but “important and critical” classes face stricter routes), and technical documentation retained for ten years. From 11 June 2026, the obligations reach importers and distributors too, who must verify the CE marking and ensure their own storage and transport do not compromise a product’s security. The SBOM is one line item on a much longer list.

Now look at the September 2026 date through an engineer’s eyes. To report an actively exploited vulnerability within 24 hours, you have to know, fast, whether a newly disclosed CVE is even present in your product. For a 2019 IoT gateway still in the field, that means you need an accurate SBOM for it and automated monitoring against vulnerability threat intelligence feeds, so that you’ve got feet on the ground and hands on keyboards the moment the clock starts ticking. The SBOM mandate technically bites in 2027, but the reporting clock in 2026 already makes SBOMs a necessity if you want to know “are we using this and if so where?” at least fifteen months earlier. The law has effectively front-loaded the hard engineering work.

NIS2: Security as a Property of the Organisation

NIS2 (Directive (EU) 2022/2555) operates at the organisational level rather than the product level. It replaced the 2016 NIS Directive, which entered into force on 18 October 2024, and 2026 is the year it stops being a transposition exercise and becomes active enforcement. Germany’s BSI issued its first NIS2 fine, 850,000 euros against a cloud provider, in February 2026. That is no longer theoretical.

It covers eighteen sectors and splits regulated organisations into “essential” and “important” entities, catching medium-sized organisations and above (roughly 50-plus employees or 10 million euros-plus turnover). The fines are up to 10 million euros or 2% of global turnover for essential entities, and 7 million euros or 1.4% for important ones.

NIS2 is less a technical checklist than a standard of organisational diligence: an all-hazards duty to manage cybersecurity risk and to be able to prove you are managing it. Article 21(2) sets out ten minimum measures every essential and important entity must implement, and they are broad: risk-analysis and information-security policies; incident handling; business continuity, backup and crisis management; supply-chain security; security in acquisition, development and maintenance (including vulnerability handling and disclosure); policies to assess whether the measures actually work; basic cyber hygiene and training; cryptography and encryption; human-resources security, access control and asset management; and multi-factor authentication with secured and emergency communications. Supply chain is one of the ten, which is worth stressing, because this is a whole-organisation security-governance regime, not a supply-chain rule.

Two of the ten cut especially close for engineers. Supply-chain security (Article 21(2)(d)) flows downhill: your enterprise customers will start demanding evidence that your components and suppliers are not a liability, and a supplier without credible vulnerability handling becomes an unacceptable procurement risk. And proving effectiveness (Article 21(2)(f)) is the genuinely hard one, because it is not enough to have a control; you have to demonstrate, on an ongoing basis, that it works.

Above all of it sits Article 20 (governance): management bodies must approve and oversee the measures, complete cybersecurity training, and can be held personally liable for failures, in some member states including temporary bans from management roles. Germany’s December 2025 BSI Act made exactly that explicit. Security is now a board-level duty that cannot be delegated to IT or indemnified away.

The reporting cadence (Article 23) mirrors the CRA shape: a 24-hour early warning, a 72-hour notification, and a one-month final report for significant incidents. And this is live, not looming: the first compliance-audit deadline fell on 30 June 2026, the Commission has referred several member states to the Court of Justice for failing to transpose on time, and the first fines have already landed.

DORA: Security as a Property of the Financial System

DORA (Regulation (EU) 2022/2554) is the financial-sector specialist. Because it is a regulation, not a directive, it applied directly across the EU from 17 January 2025 with no national transposition needed. It covers banks, insurers, investment firms, payment institutions, crypto-asset service providers and, importantly for many of my readers, the critical ICT third-party providers that serve them.

If you build SaaS, cloud, or managed services that financial institutions depend on, DORA reaches you indirectly through your contracts even if you are not a financial entity yourself.

DORA is built on five pillars, and together they amount to a full operational-resilience regime, not a security add-on. ICT risk management: a board-owned framework to identify, protect, detect, respond and recover, resting on a complete map of your systems and their dependencies. Incident management and reporting: classify ICT incidents by severity and report the major ones on a strict clock. Digital operational resilience testing: test the systems behind critical functions at least annually and, for the entities supervisors designate as significant, undergo threat-led penetration testing (TLPT) against live production at least every three years, using external testers. Third-party risk management: maintain a Register of Information covering every ICT arrangement, perform due diligence, account for concentration risk and sub-outsourcing, and put specific contractual clauses in place for audit rights, service levels and exit strategies. Information sharing: the one voluntary pillar, encouraging threat-intelligence exchange across the sector.

DORA also does something none of the others do: it creates a Union-wide Oversight Framework in which the critical ICT third-party providers that the European Supervisory Authorities designate come under direct EU oversight. If you are a large enough cloud or SaaS provider to the sector, a regulator may eventually examine you directly, not just your customers.

Two things stand out for engineers. First, the incident reporting bar is tighter than the others: major ICT-related incidents must be reported within four hours of classification, with follow-ups at 72 hours and one month. Four hours is not a window you can improvise during a live crisis; it has to be rehearsed. Second, DORA Article 5 places ultimate responsibility for ICT risk on the management body, the same accountability shift we see in NIS2.

Where DORA and NIS2 overlap, DORA wins as the more specialised regime (lex specialis). A financial entity does not satisfy DORA by complying with NIS2, or the reverse. If both apply, you map each obligation separately.

The Common Engineering Foundation

My concerns and optimism both stem from this point. The CRA, NIS2, and DORA regulations each have distinct focuses, reporting schedules, and oversight bodies, with their mandates extending well beyond the scope of a single newsletter, encompassing areas such as governance, continuity, resilience testing, and operational oversight. The same engineering foundation is present under all of them:

1. You need to know what is in your software. A machine-readable SBOM (SPDX or CycloneDX) for every product and service, covering first-party and third-party components, kept current as versions change. The CRA mandates it outright; NIS2 and DORA make it the only realistic way to meet their supply-chain and reporting duties.

2. You need to know which of those components are continuously vulnerable. Not a quarterly scan. A live correlation between your SBOM and the vulnerability feeds (OSV, the new European Vulnerability Database, vendor advisories), so that when a CVE drops you know within hours whether it touches you.

3. You need to know how exposed you are, in priority order. Which application, holding which data, depending on which weak component, matters most? This is exactly the supply-chain trust score and business-risk model I built up across Threat Modeling Your Dependencies Parts 1 and 2. The effective trust score tells you the aggregate health of a dependency chain; the minimum-path score is its counterweight, the trust score of the single weakest component anywhere in that chain, however deep it sits, so that one catastrophic dependency (a broken TLS library ten levels down, say) cannot be averaged into invisibility. Tie both to asset value and you get a prioritised, monetised view of the risk these regulators are asking you to manage.

4. You need to be able to act, and prove that you acted. A documented vulnerability-handling process, a coordinated disclosure policy, a security contact, and an audit trail. The CRA, in particular, expects you to retain technical documentation for ten years.

This isn’t unfamiliar territory if you’ve been following my SBOM-graph series. It is the same graph, the same trust scoring, the same prioritisation. This only represents a fraction of what these regimes require; the majority pertains to governance, testing, and continuity, extending beyond a single newsletter. What they all share is the underlying engineering framework, and that’s what I’m able to help you develop.

A Note on Cryptography and Provenance

Two more threads connect here. The CRA’s secure-by-design requirements include protecting the confidentiality and integrity of data, which is where the post-quantum readiness I covered in Get PQC Ready PDQ starts to matter for anything with a long support lifetime. And proving that the artefact you shipped is actually the one you built from your reviewed source is a job for build provenance, which I covered in SLSA and Provenance. Your SBOM says what is in the box; provenance says the box has not been tampered with on the way to the customer. Regulators increasingly want both.

But since writing the SLSA and Provenance article I found something about SBOMs that I think is genuinely alarming. Here’s the thing: Your SBOM is not really a “what is in the box”; it is closer to a “what was intended to go in the box”, a bit like flat-pack furniture where it said that two different hinge versions were included, but when you came to put the doors on there was only one pair and they were the wrong version. What is in the box should be the effective contents of the build artefact that was actually built. And there are three separate reasons the SBOM you produce, in full compliance, may not be that. I’m now going to explain who’s at fault and why.

First, the legal floor is too shallow to do its own job. The CRA’s SBOM obligation lives in the vulnerability-handling part of Annex I, which is telling, because its whole purpose is to let you answer “am I affected by this CVE?” Yet the text sets the depth bar on the floor. Manufacturers must “identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.” Top-level. Direct dependencies only. The overwhelming majority of exploited vulnerabilities live in transitive dependencies, the layers a top-level SBOM does not have to list at all. And this is not a quirk of the CRA alone: the 2021 NTIA Minimum Elements, the baseline nearly everyone built their tooling against, pitched depth at the top level too. A document put there to answer “Am I affected?” is permitted to stop at the tip of the iceberg; the disaster is below the waterline. Worse, the two obligations are chronologically in the wrong order. The requirement to report an actively exploited vulnerability within 24 hours comes in to force on the 11^th September 2026; the SBOM that is supposed to help you answer whether you are affected isn’t required until 11^th December 2027, and that’s only the shallow floor. The artefact meant to answer the question arrives fifteen months after the obligation to answer it, and shallower than the question needs. That’s the regulation’s fault, on both counts.

Second, I didn’t expect the two main standards to have this one covered, but they do. CycloneDX has been able to state exactly that since version 1.5, released in June 2023, well before either CRA date. Its metadata carries a lifecycles field with an enumerated phase: pre-build (“information obtained prior to a build process… The inventory may need to be resolved”), build (“information obtained during a build process where component inventory is available for use. The precise versions of resolved components are usually available at this time”), and post-build, among others. That is precisely the declared-versus-as-built distinction, named and machine-readable, three years before it was needed. The same release added Compositions, which lets a BOM declare whether its inventory is complete or unknown. So the capability to say “this is the resolved graph” or “this is only the declared one, treat it with suspicion” has been sitting in the mainstream format the whole time. What the format does not do, and says so in plain text, is make you tell the truth. The Ecma standardisation of CycloneDX (ECMA-424) states it outright: “This Standard does not define enforcement mechanisms for verifying the accuracy or completeness of a BOM.” The fields exist; the obligation to populate them honestly does not. That is a deliberate design choice, not a defect, but it hands the entire problem to the layer above.

Third, that layer is the tools and the people running them, and this is where it actually breaks. Whether your SBOM carries the declared-versus-as-built signal at all depends entirely on which generator you used and how you invoked it, and the mainstream tools all seem to do their own thing. One widely used generator sets a lifecycle phase by default (build for applications, post-build for containers, pre-build when dependency resolution is disabled), so its output tells you which view you are looking at. Another, just as widely used, doesn’t set it at all: I generated an SBOM with it with default settings, and the metadata.lifecycles field were missing, for both CycloneDX 1.6 and 1.7. Same ecosystem, same format, opposite behaviour on the one field that says whether the document reflects intent or contents. Worse, the very same generators can flip depending on how they are called: a security-conscious invocation that refuses to run dependency-install scripts (a real code-execution risk) will default to the declared pre-build view unless you explicitly ask for the resolved build one. So the fidelity of your SBOM is decided, often silently, by a default you didn’t know about.”

Layer the version conflict problem on top and it gets worse. Take a diamond dependency: two paths in your declared graph pull two different versions of the same component. Maven’s “nearest wins” mediation resolves that by shortest path to the root, keeps one, and it may not even be the newest. That is an important decision, security related or otherwise, made silently, by the build tool on behalf of an engineer. That engineer has more than likely never looked at the 3rd party code and does not know the tool is making these decisions on their behalf. A tool that reads the declared manifest rather than the built artefact will record the wrong version, or list both when only one shipped. (Maven is the example; the mechanics differ by ecosystem, npm keeps multiple versions by design, Go uses minimum-version selection, but the disconnect between the declared graph and the shipped artefact is widespread.)

None of this breaches any standard, and that is the uncomfortable part: a tool implemented faithfully to the letter of the format produces a document that is silent about, or wrong about, what shipped, and passes conformance while doing it. metadata.lifecycles and indeed metadata itself are optional elements. Compliance is not correctness here. Being scrupulously compliant can make the document more convincing at exactly the moment it is least trustworthy. I checked a production SBOM from one of our own pipelines while writing this. It carried no lifecycle phase at all, and I could not have told you offhand which tool generated it. If I cannot say whether my own bill of materials describes what I intended or what I shipped, that is the whole problem in one sentence.

And provenance does not rescue this. SLSA attests to the process that built the system; it does not attest that your SBOM correctly lists the contents. You can hold unforgeable provenance for a build whose bill of materials is quietly inaccurate.

The people who own the guidance have, to their credit, spotted this. CISA’s 2025 draft update to the Minimum Elements pulls out the top-level floor in almost confessional terms: the old depth definition, it says, “reflected the capabilities of SBOM tooling at the time rather than the depth of information needed to make informed security decisions.” It replaces it with a Coverage element requiring “all components… including transitive dependencies”, with “no minimum depth”, and, aimed squarely at the diamond case, “if there are multiple instances of a software component with differences in metadata, each instance must be listed separately”. It even adds a new field, Generation Context, that forces an SBOM to declare whether it was produced “before build, during build, [or] after build”, which is exactly the intended-versus-as-built distinction made explicit. So the fix exists. But it is a pre-decisional US public-comment draft, not the harmonised European standard the CRA will eventually point to, and that standard is still unwritten. The products shipping against September 2026 and December 2027 were built to the old floor.

So the relevance here and this is going to hurt. If you have a clock ticking on a vulnerability being exploited in the wild, and your SBOM is shallow by design, populated from the declared graph, and silent about whether it reflects what you actually built, then you do not reliably know whether you are affected. You are left choosing between slipping the reporting deadline and accepting the consequences, or reporting a vulnerability status you cannot actually substantiate from your own records.

Note to engineering leaders: Do not let the software-integrity part of this land as three separate compliance projects with three separate spreadsheets. Knowing what you actually ship, knowing which components are vulnerable, and being able to report fast is one capability, and it underpins the supply-chain and reporting duties in all three regimes. Build it once. But build it on ground you can trust: as the above shows, a declared SBOM is not yet an accurate contents list, and closing that gap, generating from the built artefact and not the manifest, is the first job, not an afterthought. It’s important to recognize that this is the common groundwork, not the complete picture: DORA’s resilience testing, NIS2’s governance duties, and the CRA’s conformity assessment are external and need independent ownership. The September 2026 CRA reporting clock is the logical starting point because of its proximity and relevance to legacy products.

Final Thoughts

I have a lot of sympathy for engineers looking at this. Three regimes, three timelines, overlapping scopes, scary fines, and personal liability for the people at the top. But the sympathy is not really about the volume anymore. It is that you can do everything these regulations ask, to the letter, and still not be able to answer that one question your being asked to answer under the gun: am I actually affected? When the compliance surface itself is contradictory, and the tools will hand you a confident answer that is wrong, the job stops being “keep up” and becomes “know what is actually true.” Build on what you can verify, the artefact you really shipped, not the document you were told to produce, and you have somewhere solid to stand while the dust settles. To do that, it may mean more work or building your own automations, AGAIN.

The intent is right. The implementation leaves a lot to be desired on two counts. From September 2026, they’ve put in place a requirement to disclose within 24 hours any exploited vulnerabilities impacting your product. The SBOM, designed to provide that answer, is not required until December 2027. Even then, it only needs to cover your main dependencies, not the deeper, transitive ones where vulnerabilities are most common. The solution you need comes fifteen months past the deadline and isn’t deep enough. Wrong depth, wrong order.

So the predicament is: to get this done, we need tools, but the tools to do the job don’t exist. So if we want to be able to interrogate what is or isn’t in our products, so that we can report on it, we’d better roll up our sleeves and build something that says what is in the box. Do that and you can answer the question straight off when the proverbial hits the fan, and not panic the day the report has to be filed.

You cannot report what you cannot see, but you also cannot trust what the tools are telling you. Fantastic stuff. So the first thing to do isn’t ticking a box, it’s finding out what’s in it. That’s core to a lot of what I write and many of the tools I have developed: you cannot secure, report on, or reason about what you don’t know, so make visibility deterministic and build up from there.

References

The claims in this piece are drawn from primary sources. Where I quote a document, the exact article or clause is named inline; full detail and links are below.

1. Regulation (EU) 2024/2847 of the European Parliament and of the Council (Cyber Resilience Act), Annex I, Part II, point (1). Official Journal of the European Union, 2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

2. NTIA, The Minimum Elements for a Software Bill of Materials (SBOM), 12 July 2021. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom (PDF: https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf)

3. CISA, 2025 Minimum Elements for a Software Bill of Materials (SBOM), Public Comment Draft, August 2025 (Depth/Coverage and Generation Context elements). https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf

4. CycloneDX v1.5 release (OWASP), 26 June 2023, introducing the lifecycles metadata field. https://cyclonedx.org/docs/1.5/json/#metadata_lifecycles

5. ECMA-424, CycloneDX Bill of Materials Specification, 1st edition (CycloneDX 1.6), June 2024, and 2nd edition (CycloneDX 1.7), December 2025. Conformance NOTE 2 (“does not define enforcement mechanisms for verifying the accuracy or completeness of a BOM”); metadata.lifecycles. https://ecma-international.org/wp-content/uploads/ECMA-424_2nd_edition_december_2025.pdf

6. SBOM generator that sets the phase by default: cdxgen documentation (ADVANCED.md), “cdxgen attempts to generate a BOM for the build lifecycle phase for applications and post-build phase for container images”; --no-install-deps yields a pre-build BOM. https://cdxgen.github.io/cdxgen/#/ADVANCED?id=build-fidelity-rules and https://cdxgen.github.io/cdxgen/#/ADVANCED?id=bom-lifecycles

7. CLI integration defaulting to the declared view: Socket CLI socket cdxgen documentation, “The lifecycle defaults to --lifecycle pre-build, which disables --install-deps to avoid arbitrary code execution during the scan.” https://docs.socket.dev/docs/socket-cdxgen

8. SBOM generator observed to omit the field: Syft v1.51.1 (Anchore), default cyclonedx-json directory scan emitted no metadata.lifecycles. (Author’s own test, September 2026.)

9. Germany’s BSI, Technical Guideline TR-03183-2 (SBOM requirements; recursive dependency resolution beyond the top-level floor). https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2_v2_1_0.pdf?__blob=publicationFile&v=6

Stay tuned!