Secure by Design: Why the EU Cyber Resilience Act Changes How Software Gets Built

September 11, 2026 is nine weeks away. Most software teams have not circled it.

That is the date the EU Cyber Resilience Act’s vulnerability reporting obligations take effect — the first concrete enforcement milestone of a regulation that applies to every product with digital elements sold in the European Union. Full compliance follows on December 11, 2027. The penalties for non-compliance reach €15 million or 2.5% of global annual revenue, whichever is higher.

The CRA is not a theoretical future requirement. It is live, it applies extraterritorially to any company selling software or software-embedded products into EU markets, and its first deadline is in two months.

Here is what the CRA actually requires, why the build-in-vs-bolt-on cost differential is enormous, and the three questions every enterprise buyer should be asking their software partners before September.

What the EU Cyber Resilience Act Actually Requires

The CRA creates legally binding security requirements for products with digital elements — hardware and software products placed on the EU market. The scope is broad: it covers everything from industrial control systems to consumer software applications to embedded devices. If it connects, communicates, or processes data, it is almost certainly in scope.

The CRA imposes three categories of obligation:

Security by design requirements. Products must be designed and developed with security integrated from the start. This means documented security architecture, assessment of the attack surface, secure default configurations, minimal exposure of attack surfaces, protection of confidentiality and integrity, and restriction of access to only what is necessary. The burden of demonstrating these properties falls on the developer — attestation without documentation does not satisfy the regulation.

Vulnerability management and disclosure. Manufacturers must have processes to identify, manage, and address vulnerabilities throughout the product lifecycle. They must actively monitor their products for security issues and apply security updates without requiring user action where possible. When exploitable vulnerabilities are discovered, the September 11 deadline triggers a 24-hour reporting obligation to ENISA (the EU cybersecurity agency) and to the national CSIRT.

Documentation and transparency. The CRA requires a software bill of materials (SBOM) — a formal inventory of software components — to accompany products. This documentation must be maintained and updated as the product evolves. Enterprises procuring software should now expect to receive and review SBOM documentation as a standard part of vendor due diligence.

The Cost of Getting It Wrong: Why Build-In Is 6–100x Cheaper

NIST research established the cost multiplier for security remediation long before the CRA existed: fixing a vulnerability after a product ships costs six to one hundred times more than addressing it during design. The CRA makes this economics lesson a legal reality.

The IBM 2024 Data Breach Report documented that the average cost of a data breach reached $4.88 million — a record high, up 10% year over year. That figure combines detection costs, regulatory response, customer notification, legal exposure, and reputational damage. For enterprises with EU market exposure, the CRA adds regulatory penalties on top of breach costs.

The path to CRA compliance looks different depending on when security was designed into the product:

Secure-by-design products built with documented security architecture, proper access controls, maintained dependency inventories, and vulnerability scanning as part of the CI/CD pipeline can demonstrate CRA compliance through their existing documentation. CE marking — the EU conformity marking required for products in scope — is achievable through the build artifacts that already exist.

Products built without security discipline face a retrofitting problem. Adding vulnerability management retroactively means auditing every component, identifying and patching unknown dependencies, building SBOM documentation from scratch for software that was never tracked that way, and implementing security monitoring on systems designed without it. This is expensive, time-consuming, and often incomplete — because security designed in from the start produces fundamentally different architecture than security bolted on after the fact.

Gartner projects that 85% of software sold to enterprise buyers will require security documentation by 2027. The CRA is accelerating that expectation. CISA’s Secure by Design report documented that 68% of software products shipped with known exploitable vulnerabilities in 2024. The market is shifting against that norm — the CRA is giving it regulatory teeth.

The Microsoft SDL Data Point Worth Knowing

Microsoft’s Security Development Lifecycle — its internal secure-by-design framework — produced products with 50% fewer critical vulnerabilities post-launch compared to products built without it. That is not a marginal improvement. It is a structural difference in outcome that comes from where in the development process security gets addressed.

The SDL insight is directly applicable to the CRA compliance question. Products built with security as an architectural property — threat modeling in design, security testing integrated into QA, dependency tracking as standard practice — produce the documentation required for CRA compliance as a natural output. Products that treat security as a checklist at the end of the project produce documentation gaps that are expensive to close.

What Viviscape Builds Differently

ViviScape builds custom software using a modern .NET stack with security integrated at every stage: OWASP Top 10 mitigations addressed from architecture through code review, dependency management that produces SBOM-compatible component tracking, CI/CD pipelines that include security scanning, and access control architecture designed around least privilege. This is not a CRA add-on — it is how the work is done.

For enterprises with EU market exposure, this means the custom software we deliver is built to produce the documentation artifacts that CRA compliance requires. The build process is the compliance process.

Three Questions to Ask Any Software Partner Before September

The September 11 vulnerability reporting deadline creates an immediate filter for enterprise software procurement. Before engaging a software development partner for any product that will be placed in EU markets, these three questions should be part of the evaluation:

1. Can you produce a software bill of materials?

An SBOM is a formal inventory of every software component in the product — libraries, frameworks, dependencies, and their versions. If a vendor cannot produce one, or if producing one would require a retroactive audit rather than generating it from existing build artifacts, that is a signal about the maturity of their development practice. CRA-compliant products need to maintain SBOM documentation over time, not just produce it once at delivery.

2. How are security vulnerabilities identified and tracked in your development process?

The CRA’s vulnerability management requirements apply to the product lifecycle, not just delivery. A development partner whose security process ends at launch cannot support CRA compliance over time. Look for evidence of continuous dependency scanning, a clear process for evaluating and applying security patches, and an understanding of how discovered vulnerabilities would be reported under the 24-hour obligation.

3. How does your development process produce CE marking documentation?

For products in scope for the CRA, CE marking is the conformity marking demonstrating compliance with EU requirements. Achieving CE marking requires documented evidence of the security properties the CRA mandates. A development partner should be able to explain what documentation their process produces and how it maps to CE marking requirements — not just acknowledge that documentation will eventually be needed.

Key Takeaways

• The EU CRA’s first enforcement milestone — 24-hour vulnerability reporting obligations — takes effect September 11, 2026, nine weeks from publication
• The CRA applies extraterritorially: any product with digital elements sold in EU markets is in scope regardless of where the developer or deployer is based
• Penalties reach €15 million or 2.5% of global annual revenue — on top of breach costs that averaged $4.88 million in 2024
• NIST research documents that fixing vulnerabilities after deployment costs 6–100x more than addressing them in design — the CRA makes this a compliance cost, not just a quality cost
• Products built with security architecture from day one produce CRA compliance documentation as a natural build artifact; retrofitting costs more and produces incomplete results
• Three procurement questions for any software partner before September: Can they produce an SBOM? How do they track vulnerabilities during development? How does their process support CE marking?