CRA Is a Product Philosophy.

An editorial by Steve Atkins, The Quantum Space

There is a pattern in how European regulation lands on the technology industry. First comes the announcement. Then the scramble to understand scope. Then the consultancy market blooms. And finally, somewhere around the deadline, the industry collectively asks the question it should have asked three years earlier: what does this actually require us to change?

The Cyber Resilience Act is following that arc. It entered into force in December 2024. Reporting obligations begin in September 2026. Full application lands in December 2027. And right now, in March 2026, we are precisely in the moment where organisations are reading the guidance — the European Commission only published its draft implementation guidance for feedback this month — and beginning to reckon with what compliance will actually involve at the product level.

I want to make a case that the wrong framing is already dominating that conversation.

The compliance framing is the wrong framing

When organisations ask “how do we comply with the CRA”, they are treating it as a box to be checked. The legal obligation is real — failure to comply risks fines of up to €15 million or 2.5 percent of global annual turnover — and so the legal and compliance teams take the lead. Standards are mapped. Documentation requirements are catalogued. Conformity assessment processes are scoped.

None of that is wrong. But it starts in the wrong place.

The CRA is, at its core, a statement about what software products should be. It requires security by design. It mandates vulnerability management throughout the product lifecycle. It demands that manufacturers know what is in their products — the SBOM obligation — and that they can report actively exploited vulnerabilities within 24 hours of awareness. These are not administrative requirements. They are engineering requirements. They are architecture requirements. They are, fundamentally, product philosophy requirements.

The question is not “how do we document what we already do well enough to satisfy a notified body.” The question is “are we building products that deserve to be on the market.”

What the CRA actually asks of software vendors

The Act applies to what it calls products with digital elements — hardware, software, and their remote data processing solutions. The scope is deliberately wide. If it connects to a network, directly or indirectly, it is likely in scope.

For software vendors, the implications are specific and substantial. Security must be considered from the design phase, not retrofitted at release. Known vulnerabilities must be addressed without undue delay. Products must ship in a secure default configuration. And when vulnerabilities are discovered after deployment, the reporting obligations are tight: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available.

That 24-hour clock is the part most organisations are not ready for. Knowing that a vulnerability is being actively exploited requires monitoring infrastructure, threat intelligence, and internal escalation processes that many vendors simply do not have in place. The deadline is not the problem. The absence of the underlying capability is the problem — and that absence has been there for years. The CRA is making it visible.

The SBOM question

The software bill of materials requirement is the provision I find most revealing. Knowing what is in your product sounds trivial. For most software organisations, it is not.

Modern software is assembled from dependencies, libraries, third-party components, open-source modules, and upstream integrations. The thing a customer installs is rarely what any single engineering team wrote. The CRA requires manufacturers to maintain a complete, machine-readable, standardised record of those components — and to track vulnerabilities across all of them throughout the supported lifetime of the product.

For industrial software where products may have support periods exceeding ten years, this is not a documentation task. It is a continuous operational commitment. It requires tooling, process, and a level of supply chain visibility that most vendors have not historically needed to maintain.

The Trust Stack dimension

At TQS we describe trust in software systems as a stack. Identity governs participation. Cryptography preserves integrity. Security ensures resilience. And as we have argued recently, licensing governs permitted behaviour.

The CRA sits across all four of those layers but most directly in the security layer. It operationalises what security resilience actually means for products placed on the European market: not an aspiration, not a best-effort commitment, but a documented, verifiable, time-bound obligation.

That is not a burden. It is a clarification. For vendors who have treated security as a feature, the CRA reframes it as infrastructure. For those who have already built that way, it is confirmation that the market will eventually catch up to the right way of doing things.

The question for every software vendor right now is straightforward: when the deadline arrives, will you have earned the compliance, or merely documented your way toward it?

Those are different things. And the difference will show.

---

Steve Atkins is the founder of The Quantum Space. This editorial reflects his personal perspective on technology, trust, and digital governance.