The European Union’s Cyber Resilience Act (CRA) is now firmly on the horizon, with the first of two implementation stages set to begin on September 11, 2026, just a few weeks from now. In that first stage, manufacturers will need to start reporting actively exploited vulnerabilities and severe incidents to European authorities on a tight 24-hour clock. The rest of the regulation—the essential requirements, the conformity assessment, and the CE marking—will apply beginning December 11, 2027.

If you sell software in the European Union, you’re now well past the point where you can safely put off thinking about the CRA. And because it applies to anything in the extremely broad category of “products with digital elements,” you’ll need to be well prepared even if your company isn’t headquartered in the EU. That category covers physical products just as much as software you deliver over a network: a robot, an industrial controller, or any connected device counts. Most of the CRA urgency we hear about, in fact, comes from robotics companies, and for good reason: the obligations bite hardest when your software runs on hardware that’s already out in the world. We’ll have quite a bit more to say about Nix on physical devices in the near future, so watch this space. In this post, however, I’d like to convince you that nothing in the CRA is truly ominous because Nix and the Determinate platform provide a comprehensive and foundationally sound solution to the software supply chain requirements that the CRA presents.

What the CRA demands

Let’s start with a closer look at what the CRA actually involves for those who aren’t yet familiar. Regulation (EU) 2024/2847 entered into force on December 10, 2024, and most of what it calls for is pretty standard security hygiene. Some parts that touch on the software supply chain:

• Demonstrating what’s in your product. Annex I, Part II, point 1 requires you to identify and document the components in your product, “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.” The Software Bill of Materials (SBOM) has to be kept current and provided to proper authorities on request. Pay attention to the phrase “at the very least,” because top-level dependencies are the bare minimum of what SBOMs need to provide.
• Shipping without known exploitable vulnerabilities. Annex I, Part I requires products to be made available on the market (a) without any known exploitable vulnerabilities, and (b) with a secure-by-default configuration and a minimized attack surface.
• Remediation without delay, for at least five years. Annex I, Part II requires you to address vulnerabilities without delay and to provide security updates, while Article 13(8) sets the support period at a minimum of five years unless the product’s expected use is shorter. Five years is a long time to keep a build reproducible, and the clock is especially punishing if you ship to edge or remote devices, where “provide a security update” means rebuilding an image for hardware you no longer physically control.
• Due diligence even on code you didn’t write. Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components “so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software.”
• Report fast. Article 14 gives you 24 hours for an early warning, 72 hours for a fuller vulnerability notification, and 14 days for a final report, filed with the European Union Agency for Cybersecurity (ENISA) and the relevant Computer Security Incident Response Team (CSIRT). This is the obligation that will kick in next month (September 2026).
• Getting it wrong is expensive. Article 64 sets penalties for breaching the essential requirements at up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher (yikes!).

There’s also an important nuance for anyone building on open source. Individual maintainers and non-commercial projects are largely outside the CRA’s scope, and “open-source stewards” like foundations are subject to a lighter set of obligations. For Nix shops, note that if you ship a product built using Nixpkgs, you are considered the manufacturer, and the due diligence obligation now rests on your shoulders—not those of Nixpkgs maintainers.

The challenge

To understand these requirements more intuitively, let’s consider a concrete case. Your company ships a product with digital elements into the EU, whether that’s an appliance, a fleet of robots running Linux out in the field, or the remote data processing that one of those products can’t function without. At 9 am on a Tuesday, a vulnerability is disclosed in a low-level compression library. The chatter on Hacker News and Reddit and other forums suggests that this one is really bad.

When the CRA is in full force, you’ll be on the hook to answer a variety of questions. Are you affected? Which of your products? Which versions? And if some of those versions are running on devices you shipped two years ago, which of those do you need to reach, and how fast can you get a fix onto them?

You can’t answer these questions in 24 hours if answering “what is actually in this artifact?” takes you a week of frantically tracking down information after the fact. And yet this after-the-fact approach is still standard practice: scan the artifact, parse the lockfiles you know about, ask around internally, and hope the build machine didn’t contribute anything “exciting” of its own.

This is the “what” problem we described in our FlakeBOM announcement post a while back, and it includes not just final software artifacts but also things like build tools and vendored dependencies. The challenge presented by the CRA boils down to being able to answer “what” questions quickly and with minimal extra engineering effort. But your ability to meet this challenge will be a direct function of fundamental supply chain decisions that you make. This is where Nix enters the picture.

Nix and the “what” question

As I hinted at the beginning, Nix is fundamentally the answer to the “what” questions posed by the CRA. In a recent post, I argued that Nix provides our industry its best chance at solving supply chain security because it provides radical transparency into how software is built. And it provides that not as a feature or add-on but rather by virtue of its core constructs.

So let’s look at four properties of Nix that map directly onto what the CRA asks of you.

Closures are your component inventory. The CRA asks for top-level dependencies as a minimum. A Nix closure is the complete transitive set of everything needed to build or run a piece of software, and completeness is its defining property. You don’t need to reconstruct Nix closures through scanning, inference, or some other method. You examine closures because Nix always uses them to build things.

Derivations codify your build. Every build in Nix is described by an introspectable data structure called a derivation that records the builder, the build arguments, the system, the patches applied, every input, and more. Annex VII of the CRA mandates a description of the design, development, and production of your product. Nix keeps these records as part of its basic functioning, for every dependency in your graph.

Sandboxing is your build integrity story. Nix builds run inside the Nix sandbox, with no arbitrary network or filesystem access, so the built artifact is a function of the declared dependencies and nothing else. Ambient state on a build machine—a compiler in /usr/bin, a header file in /usr/include—can’t quietly corrupt what you ship, so your SBOM faithfully describes the thing you actually shipped.

Package interdependence is your remediation lever. Because packages in a set like Nixpkgs are one vast dependency graph, patching a vulnerable library or package once and rebuilding everything downstream is a single operation rather than a web of updates across a set of repositories. This makes “address and remediate without delay,” as the CRA puts it, a far easier promise to keep than it is in build paradigms outside Nix.

Again, none of this—closures, derivations, and so on—is an optional feature that you need to switch on to get desirable results. It’s just how Nix works. But Nix by itself doesn’t quite cross the chasm from sound core constructs to the concrete deliverables that the CRA requires. This is where the Determinate platform steps in.

Determinate Secure Packages as the basis of your supply chain

Article 13(5) of the CRA mandates that you exercise due diligence with regard to open source components that you integrate. That means that your team owns the security posture of every package in your dependency graph. If you’re using Nixpkgs, which has well over 100,000 packages, that’s a pretty tall order. And due diligence is only half of it, because Annex I asks you to not just report but actually fix what you find, without delay, for five years.

Determinate Secure Packages provides both the due diligence and the remediation, handled for you by our team of Nix security specialists:

• A curated package set of over 10,000 packages based on Nixpkgs, so the scope of what you’re vouching for is a set that we actively maintain (rather than the entire universe of packages).
• Common Vulnerabilities and Exposures (CVE) remediation backed by a service-level agreement (SLA), which is pretty close to a contractual version of “without delay.”
• Packages built, signed, and distributed from SOC-2-Type-II-compliant infrastructure, with full cache coverage in FlakeHub Cache, so provenance is provable rather than assumed.
• Optional Federal Information Processing Standards (FIPS) variants for teams that are also bound by US federal cryptographic requirements.
• Curated vulnerability metadata, including Common Platform Enumeration (CPE) identifiers that upstream Nixpkgs mostly lacks, plus triage recorded as Vulnerability Exploitability eXchange (VEX) metadata alongside the packages themselves.

That last point is worth focusing on because it’s what makes automated scanning particularly meaningful with Determinate Secure Packages. A scanner can only match the information that a package provides, and upstream Nixpkgs doesn’t carry identifiers for most of its packages. We add those identifiers ourselves, and when we triage a vulnerability we record the analysis (affected, not affected, in triage, and why) directly in the provenance metadata.

From an ergonomic perspective, adopting all of the above essentially involves swapping a flakeref:

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
  inputs.nixpkgs.url =
    "https://flakehub.com/f/DeterminateSystems/secure-packages-26.05/0";
}

No integration, no refactoring, just a new package source backed by our team (and SLAs).

FlakeBOM produces the SBOM the CRA describes

Our tool FlakeBOM, included with Determinate Secure Packages, generates CycloneDX 1.5 JSON SBOMs from any Nix flake. That is, almost word for word, the “commonly used and machine-readable format” that the CRA mandates.

cd /path/to/my/flake

flakebom

FlakeBOM is great for this specific problem:

It goes far past top-level dependencies. FlakeBOM walks your flake’s schema and recursively collects every derivation it reaches, so that what you get is the full closure rather than a summary of it. It also detects vendored dependencies inside derivations like fetchNpmDeps and fetchCargoVendor, realises them, parses the lockfiles inside, and lists what it finds as sub-components with Package URL (PURL) identifiers attached. Those blobs are precisely where after-the-fact scanners often struggle.

It carries the triage with it. When you run FlakeBOM against Determinate Secure Packages, our VEX analysis “rides along” in the SBOM, so that the document doesn’t just say what you have, it says what we already know about your flake.

It’s fast enough to run every build. We routinely generate a roughly 60MiB SBOM covering the entire secure package set (more than 10,000 components) in under two minutes, thanks to Determinate Nix’s parallel evaluation. The CRA requires the SBOM to be kept up to date, and the reliable way to keep a document current is to regenerate it as a build artifact rather than maintaining it by hand.

FlakeAudit turns the SBOM into a control

An SBOM by itself is a report on what exists. But the CRA mandates something much more exacting: that you don’t ship known exploitable vulnerabilities and that you show your work. FlakeAudit is what makes the SBOM document enforceable, through three subcommands that map onto three CRA obligations.

flakeaudit check is your “no known exploitable vulnerabilities” gate. You express policy in a flakeaudit.toml file, and any violation fails your CI run with a non-zero exit. Here’s an example CRA-friendly config:

[vulnerabilities]
severity-floor = "high"

[vulnerabilities.state]
exploitable = "deny"
untriaged = "deny"
in-triage = "warn"
resolved = "allow"
not-affected = "allow"

Read that policy as a sentence and it’s close to the regulation’s language: nothing exploitable ships, nothing untriaged ships, anything mid-triage is visible, and anything we’ve already reasoned about passes. The same file also governs license policy through Software Package Data Exchange (SPDX) expressions, component bans with per-component exceptions, and an allowlist of acceptable PURL ecosystems.

flakeaudit scan feeds the 24-hour clock. It queries the National Vulnerability Database (NVD) and osv.dev for advisories affecting your components and writes them back into the SBOM. When a vulnerability lands at 9 am on a Tuesday, the question “which of our products contain this?” becomes a query against documents you already have rather than an investigation you have to kick off.

flakeaudit compare is your change reporting. It diffs two SBOMs, and its deriver and callstack matchers use the Nix-specific metadata FlakeBOM emits to tell you precisely what changed between two builds. That’s the answer to the “what’s different in this release?” question, which is good to know during an incident, during an audit, and into the indefinite future.

flakeaudit compare sbom-baseline.cdx.json sbom-target.cdx.json \
  --matcher deriver \
  --method diff \
  --output diff.json

Both tools are Rust binaries available today to Determinate Secure Packages customers. No platform to stand up, no artifacts to upload to somebody else’s cloud, and no policy DSL to re-implement.

Where to start

If the CRA applies to you, here’s what we recommend doing between now and December 2027, in roughly this order:

1. Before September 11: Make sure you know who files an Article 14 report, how, and from what evidence. Generate an SBOM for everything you ship into the EU today, even a rough one, so that the reporting question has a factual starting point.
2. This quarter: Move your nixpkgs input to Determinate Secure Packages so that the due diligence obligation has an owner and your packages start carrying identifiers and triage data. Then start running flakebom in CI and storing the output as a release artifact.
3. Before the December 2027 deadline: Encode your policy in flakeaudit.toml, wire flakeaudit check into CI as a blocking step, and keep a baseline SBOM per release so that flakeaudit compare has something to compare against. Baselines are worth establishing early, since the first one you’ll wish you had is the one from before the incident.

The teams that have the easiest time with the CRA will be the ones that put a solid supply chain pipeline in place well before the deadlines.

Get in touch

If you’d like to see how Determinate Secure Packages, FlakeBOM, and FlakeAudit fit into your pipeline, schedule a demo or ask us questions at sales@determinate.systems, or come find us on Discord.