What Is the EU Cyber Resilience Act?
The EU Cyber Resilience Act (CRA) is an EU regulation that sets horizontal cybersecurity requirements for “products with digital elements” (software and hardware that can connect directly or indirectly to a device or network). Its goal is to raise the baseline security of products sold in the EU by requiring security to be addressed across the full product lifecycle, not just at release time.
The CRA was adopted as Regulation (EU) 2024/2847. As an EU regulation, it is directly applicable across EU Member States (no national transposition like a directive).
Practically, the CRA combines:
- Product security requirements (design/development/production expectations)
- Vulnerability handling obligations (support periods, disclosure, updates, SBOM expectations)
- Conformity assessment and CE marking requirements to demonstrate compliance before placing products on the EU market
Why CRA Matters
For manufacturers and vendors, CRA compliance is becoming a market access requirement for many product categories sold into the EU. It also affects procurement, partner due diligence, and customer security questionnaires because the CRA formalizes expectations like “secure-by-default,” timely security updates, and structured vulnerability handling.
It also changes what “good security hygiene” looks like in audits and investigations. If a product ships with weak defaults, lacks a credible vulnerability process, or cannot demonstrate conformity assessment evidence, the risk is not only security exposure but also regulatory enforcement, reputational damage, and commercial friction (delayed sales, blocked deployments, escalated enterprise reviews).
Timing matters too. The European Commission’s CRA materials describe phased applicability, with earlier effective dates for certain obligations and the main obligations applying later.
What the Framework Says
A CRA requirement that directly connects to configuration management and hardening is the secure default expectation:
“be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state;”
Reference: Regulation (EU) 2024/… (Cyber Resilience Act), Annex I, Part I, point (2)(b)
Official source: Council / Parliament legislative act (PE-CONS 100/23) PDF
What CRA Requires
At a practical level, the CRA expects manufacturers to prove they have built security into the product lifecycle, and can maintain it after release. Key themes include risk-based requirements, secure defaults, updateability, access control, data protection, logging/monitoring capability, and mature vulnerability handling.
Major requirements commonly translating into engineering and compliance work include:
- Technical documentation + conformity assessment + CE marking evidence trai
- Cybersecurity risk assessment to drive security design decisions
- Secure-by-default configuration at time of market placement
- No known exploitable vulnerabilities when made available on the market
- Security update capability (including mechanisms for distribution and timeliness)
- Protection against unauthorized access (e.g., auth/access control mechanisms)
- Confidentiality and integrity protections, including for configuration and data
- Security logging/monitoring capability (product-level telemetry expectations)
- Vulnerability handling program, including coordinated disclosure and public advisory practice
- SBOM expectation (at least top-level dependencies) and component visibility
EU CRA Implementation Guidance
Use this as an implementation checklist you can turn into a work plan:
☐ Define which offerings are products with digital elements and identify exclusions/overlaps with other EU rules
☐ Build a cybersecurity risk assessment process that feeds product requirements and release gates
☐ Establish a secure configuration baseline per product (defaults, hardening posture, reset-to-secure state)
☐ Implement controls to prevent shipping with known exploitable vulnerabilities (scanning + remediation gates)
☐ Create a security update process (signing, secure distribution, rollback, advisory communications)
☐ Implement access control and protect sensitive functions, interfaces, and management planes
☐ Ensure integrity protections for firmware/software/configuration (tamper resistance, verification, logging)
☐ Stand up a vulnerability handling program (intake, triage, SLAs, coordinated disclosure policy)
☐ Produce and maintain an SBOM (at minimum top-level dependencies) and track third-party components
☐ Prepare technical documentation and conformity assessment evidence to support CE marking claims
How to Prepare for a CRA Audit or Market Surveillance Review
Define scope and product inventory
Start with a product inventory and decide which are in scope as “products with digital elements,” including any remote data processing solutions provided by the manufacturer that are necessary for product functions. Tie each product to owners, release trains, and support periods.
Translate Annex I into verifiable controls
Turn Annex I requirements into testable statements, for example:
- “Default admin interfaces are disabled unless explicitly enabled”
- “Cryptographic settings meet defined minimums”
- “Configuration changes are authenticated, logged, and reviewable”
- “Security updates are signed and delivered over a secure channel”
This is where secure configuration baselines become “audit evidence,” not just engineering intent.
Establish and enforce secure configuration baselines
Document baseline settings per product (and per deployment mode). The CRA’s secure-by-default expectation is easiest to defend when you can show:
- Baseline configuration documentation
- Automated configuration validation tests
- A reset-to-secure mechanism (where applicable)
- Evidence that shipped defaults match what you documented
Implement change control that protects integrity
Treat product configuration like code: peer review, approvals, traceability, and separation of duties for high-risk changes. Build an evidence trail that connects: change request → implementation → test results → release artifact. This reduces the risk that a market surveillance request becomes a fire drill.
Operationalize vulnerability handling and updates
Create measurable vulnerability handling operations:
- Intake channels and a coordinated disclosure policy
- Triage severity model and remediation SLAs
- Patch development and secure distribution
- Customer advisories and version tracking
Also ensure you can prove what happened and when (tickets, timelines, release notes, advisories).
Prepare the “evidence pack”
For each product line, assemble:
- Risk assessment outputs
- Secure default baseline + validation results
- Vulnerability management policies and records
- Update/signing/distribution procedures
- Technical documentation and conformity assessment artifacts
This is the difference between “we do security” and “we can demonstrate compliance.”
How CalCom Helps
CalCom supports CRA-aligned execution by making secure configuration and continuous verification operational:
- Enforce hardened baselines for Windows and Linux systems used to build, test, sign, and operate product services (reducing risk of insecure defaults and weak build environments).
- Detect configuration drift so approved secure defaults and operational settings remain intact over time.
- Restrict unauthorized changes by aligning configuration state with controlled change processes.
- Monitor system integrity to surface unexpected changes that could undermine product security or update trust chains.
- Generate audit-ready compliance reports that map configuration state, deviations, and remediation actions into evidence you can reuse for internal audits, customer due diligence, and regulatory reviews.
