Adaptive Logo
Product
View Product
Use Cases
View Product
Resources
View Product
Pricing
Partners
Careers
General 6 min read

EU Cyber Resilience Act (CRA): The Secure-by-Design Compliance Guide

Debarshi BasakAug 3, 2026
EU Cyber Resilience Act (CRA): The Secure-by-Design Compliance Guide

Why the CRA Matters Right Now

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.


The CRA Timeline at a Glance

DateWhat applies
December 10, 2024CRA entered into force
September 11, 2026Reporting obligations begin: 24-hour early warning for actively exploited vulnerabilities and severe incidents, 72-hour detailed notification, followed by a final report
December 11, 2027Full 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.


What "Secure by Design" Means Under the CRA

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:

  • Ship with a secure-by-default configuration
  • Are made available without known exploitable vulnerabilities
  • Ensure protection from unauthorized access through appropriate control mechanisms — authentication, identity, and access management
  • Protect the confidentiality and integrity of data at rest and in transit
  • Minimize their attack surface, including external interfaces
  • Record and monitor relevant internal activity, including access to data, services, or functions

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.


CRA Readiness Checklist

1. Scope and Classification

  • Inventory every product with digital elements you place on the EU market.
  • Determine whether any product falls into the important (Class I / Class II) or critical categories, which face stricter conformity assessment.
  • Identify your role in the chain: manufacturer, importer, or distributor — obligations differ.

2. Governance and Documentation

  • Assign ownership for CRA compliance (product security + legal).
  • Prepare technical documentation covering design, development, and vulnerability handling.
  • Draft your risk assessment for each product, mapped to Annex I requirements.
  • Stand up a coordinated vulnerability disclosure (CVD) policy and a public contact point.

3. Vulnerability Handling and Reporting (due September 11, 2026)

  • Generate and maintain an SBOM for every product.
  • Establish 24/7 capability to file an early warning within 24 hours to ENISA and your CSIRT.
  • Define the escalation path for the 72-hour notification and final report.
  • Test the process with a tabletop exercise before September.

4. Secure-by-Design Technical Controls (due December 11, 2027)

  • Eliminate static, shared, and hardcoded credentials across build, deploy, and runtime infrastructure.
  • Enforce deny-by-default access with explicit, time-bound grants.
  • Require MFA and SSO-backed identity for every human and non-human actor touching production.
  • Encrypt all access paths — no databases, SSH endpoints, or Kubernetes APIs exposed to the public internet.
  • Capture identity-attributed audit logs of every query, command, and session.
  • Apply least privilege at the resource level, not just at the cloud IAM level.

Where Adaptive Fits: Secure-by-Design for Your Infrastructure

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 expectationHow Adaptive helps
Protection from unauthorized access; access control mechanismsSSO-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 surfaceResources 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 credentialsEphemeral credentials and Just-in-Time access — real resource credentials are never revealed to users, and privileges expire automatically
Confidentiality and integrity of dataEncrypted tunnels end to end, plus Data Masking so sensitive fields never leave the database unprotected
Record and monitor internal activitySession 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 responseCentralized, 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.


Frequently Asked Questions (FAQ)

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.


Final Thoughts

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.

References
  1. Adaptivehttps://adaptive.live
  2. Just-in-Time accesshttps://adaptive.live/usecases/reduce-insider-threat
  3. access security requirements across major compliance frameworkshttps://adaptive.live/blog/access-security-requirements-across-major-compliance-frameworks
Agents are the new perimeter. Contain the chaos.
No Network Changes Required
Cloud or On-Premises Deployment
Enterprise-Grade Security