
The EU Cyber Resilience Act (CRA) entered into force on December 10, 2024, and its first obligations are no longer on the horizon — they are weeks away. From September 11, 2026, manufacturers must report actively exploited vulnerabilities to ENISA and their national CSIRT within 24 hours. The bulk of the regulation — including the essential cybersecurity requirements of Annex I and CE marking — applies from December 11, 2027.
The CRA covers nearly every product with digital elements placed on the EU market: software products, connected devices, and the remote data processing that is integral to them. Non-compliance carries penalties of up to €15 million or 2.5% of global annual turnover, whichever is higher.
Unlike a certification you can prepare for in a sprint, the CRA demands something structural: products and the infrastructure behind them must be secure by design — and you must be able to prove it with evidence, not policy documents.
| Date | What applies |
|---|---|
| December 10, 2024 | CRA entered into force |
| September 11, 2026 | Reporting obligations begin: 24-hour early warning for actively exploited vulnerabilities and severe incidents, 72-hour detailed notification, followed by a final report |
| December 11, 2027 | Full application: Annex I essential requirements, vulnerability handling, SBOM, technical documentation, and CE marking |
If you ship software or connected products into the EU, the September 2026 reporting deadline applies even to products shipped years ago. You cannot report a vulnerability within 24 hours if you don't have the visibility to detect it — which is why the reporting obligation quietly forces the rest of the secure-by-design agenda forward.
Annex I of the CRA splits its essential requirements into two parts.
Part I — Product security properties. Products with digital elements must be designed, developed, and produced so that they:
Part II — Vulnerability handling. Manufacturers must identify and document components (SBOM), remediate vulnerabilities without delay, run coordinated disclosure, and distribute security updates promptly.
Read that list again with an infrastructure lens. Authentication and access control, least privilege, encrypted transport, minimized attack surface, and activity logging — the CRA is essentially codifying infrastructure access management into product law. Secure-by-design fails in practice at the same places it always has: shared credentials in Slack, standing admin privileges, database ports exposed to the internet, and access nobody can attribute to a person.
The CRA asks you to demonstrate that access to your product's infrastructure is controlled, minimal, encrypted, and auditable. This is precisely the layer Adaptive was built for.
| CRA Annex I expectation | How Adaptive helps |
|---|---|
| Protection from unauthorized access; access control mechanisms | SSO-backed access to databases, servers, and Kubernetes clusters — including resources that don't natively support SSO — with MFA enforced through your identity provider |
| Secure-by-default configuration; minimized attack surface | Resources stay private to the network; Adaptive creates ephemeral secure tunnels, so no database port or SSH endpoint is exposed publicly and no VPN or bastion sprawl is required |
| No standing, exploitable credentials | Ephemeral credentials and Just-in-Time access — real resource credentials are never revealed to users, and privileges expire automatically |
| Confidentiality and integrity of data | Encrypted tunnels end to end, plus Data Masking so sensitive fields never leave the database unprotected |
| Record and monitor internal activity | Session Recording and Activity Monitoring attribute every query and command to a named identity — evidence you can hand directly to a conformity assessor |
| Vulnerability handling and incident response | Centralized, tamper-resistant audit trails shorten investigation time, which is what makes a 24-hour early warning achievable in practice |
Because Adaptive is agentless and container-based, deploying it doesn't add a new component inside your product's target resources — it reduces your attack surface rather than expanding your SBOM.
Q: Does the CRA apply to SaaS? Pure SaaS is generally covered by NIS2 rather than the CRA — but remote data processing that is integral to a product with digital elements falls within CRA scope. Many hybrid products will be covered.
Q: What happens if we miss the September 11, 2026 reporting deadline? Reporting failures are enforceable independently of the 2027 requirements, with fines of up to €10 million or 2% of global turnover for breaches of reporting and other obligations, and up to €15 million or 2.5% for breaches of the essential requirements.
Q: Is CE marking really required for software? Yes. From December 11, 2027, products with digital elements need a CE marking backed by a conformity assessment — self-assessment for default-category products, third-party involvement for important and critical classes.
Q: How does the CRA relate to NIS2 and ISO 27001? NIS2 regulates organizations; the CRA regulates products. ISO 27001 helps demonstrate organizational maturity, but CRA conformity requires product-level evidence. Our guide to access security requirements across major compliance frameworks shows how these overlap.
The CRA turns decades of "security best practice" into enforceable product law. The organizations that will clear it comfortably are not the ones with the thickest policy binders — they are the ones whose infrastructure makes insecure access impossible by default: no shared credentials, no standing privileges, no unaudited sessions.
Start with the September 2026 reporting obligation, because it is first and it is unforgiving. Then work the Annex I checklist backward from December 2027. If eliminating credential sprawl and producing identity-attributed audit evidence is the gap, Adaptive can close it in days, not quarters — without an agent in sight.

