The Cyber Resilience Act asks what is inside your software. But what is inside the black box?

As a freelance project manager, I do not read this as a purely technical problem but as a delivery question. The CRA touches your scope, your planning, your supplier agreements and, maybe the most important one, who signs for the risk when it goes wrong. This belongs on the steering committee, not only with the security team. Hence this piece, written from the perspective of someone whose job is to make technology and the business talk to each other.

The Cyber Resilience Act asks a question that sounds simple: what is in your software?

For classic code, we have an answer. It is called an SBOM, a Software Bill of Materials, an inventory of every component, library and dependency. The CRA makes it mandatory. Annex I requires a machine-readable SBOM covering at least your top-level dependencies, kept current for the support period, as part of your technical documentation and available to market surveillance authorities on request. Full compliance is due by 11 December 2027, and the obligation to report actively exploited vulnerabilities starts even earlier, on 11 September 2026.

So much for the theory. Now the reality. Your software today contains AI. A model in a feature, an API call to an LLM, a recommendation engine you can no longer fully explain. And that is where the SBOM logic breaks.

An SBOM assumes you can inspect your components

For a library, you can. You know the version, the known vulnerabilities, whether a patch exists. For an AI model, you cannot. You can document "we use model X", but not what is actually inside the black box: the training data, the weights, the behaviour at the edges, the dependencies you never see. You have a component in your product whose interior you do not know. And that is exactly the kind of thing the CRA asks you to control.

The industry answer is the AI-BOM, an extension of the SBOM idea to AI-specific elements: models, prompts, agents, frameworks, with the metadata to govern them. Useful, and becoming the norm. But do not be fooled. An AI-BOM tells you that a model is present in your software. It does not tell you whether that model is safe or exploitable in your context. Better inventory, not a conclusion.

This is where ISO 42001 comes in

Where the SBOM and the AI-BOM tell you what is inside, ISO 42001 is the management system that forces you to act on it. It requires you to inventory your AI systems, document design and data handling, run impact assessments across the full lifecycle, and validate provenance and integrity. In short, it is how you take accountability for the part of your software you cannot open.

One important caveat, because I see a lot of overconfidence here: ISO 42001 does not automatically cover everything the AI Act asks of you. A separate European standard (prEN 18286) is even being developed to close that gap. A 42001 certificate is therefore not a free pass. It is a foundation, not a finish line. Treat it as a checkbox and the first audit that digs past the binder of policies will find you out.

What does this mean for you in practice?

Four steps you can take yourself, extending the classic SBOM approach:

1. Build an inventory of your AI. Not "do we use AI", but: which models, in which systems, with which data, with which owner. Most organisations cannot answer that question today, and you cannot control what you cannot see.
2. Demand transparency from your suppliers. Model cards, data provenance, a statement on training data and known limitations. If you do not build the model yourself, this is your only window into the black box. Put it in the contract.
3. Bring VEX-style logic to your AI. A model's vulnerability or limitation is not a real risk in every context. Assess per use whether it is genuinely exploitable in your application, and document that judgement.
4. Connect it to a risk assessment. An inventory without threat modeling stays a document without a conclusion. Run a brief exercise for your most critical AI systems, and repeat it.

The bottom line

The CRA asks what is in the box. For code, you answer with an SBOM. For AI, you cannot open the box, which makes the question harder and more important at the same time. ISO 42001 is not the answer to everything, but it is how you demonstrably take accountability for the part you cannot see.

A certificate on the wall is not the same as knowing what is inside your black box. The difference between those two is where most organisations will stumble over the next two years.