The EU Cyber Resilience Act's first major deadline is September 11, 2026. If you're reading this in mid-2024 or later, you've got about 24 months to figure out where your organization fits in the compliance framework. Here's the issue: 66% of respondents in the 2026 CRA Awareness and Readiness Report were unfamiliar with the regulation.
This guide helps you identify your role under the CRA and map it to specific obligations. Bookmark it. You'll need it during planning sessions.
Scope - What This Guide Covers
This field guide addresses role identification and initial compliance mapping for the EU Cyber Resilience Act. It's written for:
- Security engineers at software vendors
- Compliance managers coordinating CRA readiness
- Open source maintainers whose projects may fall under CRA scope
- Product teams building "products with digital elements"
We're not covering every CRA article here. We're focusing on the practical question: "What am I responsible for?" Once you know that, you can build your compliance roadmap.
Key Concepts and Definitions
Product with Digital Elements: Hardware or software intended for commercial or non-commercial activities. This includes embedded software, standalone applications, and components integrated into larger systems.
Economic Operator: The CRA defines four primary roles:
- Manufacturer: Creates the product or has it designed/manufactured under their name
- Importer: Places products from outside the EU onto the EU market
- Distributor: Makes products available on the market (excluding manufacturer or importer activities)
- Open Source Software Steward: Provides support on a sustained basis for developing a product with digital elements that's not under open source license
Substantial Modification: Changes that affect compliance with CRA requirements. If you modify a product substantially, you may assume manufacturer obligations for that modification.
Free and Open Source Software (FOSS) Exception: Products developed or supplied outside commercial activity aren't covered by the CRA. But if you provide commercial support, integrate FOSS into a commercial product, or monetize it, you may lose this exception.
Requirements Breakdown
Manufacturer Obligations
If you're the manufacturer, you're responsible for:
- Cybersecurity Risk Assessment: Document threats throughout the product lifecycle.
- Secure by Default Configuration: Products must ship with security features enabled.
- Vulnerability Handling: Establish a coordinated disclosure process and remediation timeline.
- Documentation: Provide instructions for secure installation, configuration, and use.
- Conformity Assessment: Self-assess for most products; third-party assessment for "important" or "critical" products.
- CE Marking: Affix the marking once you've completed conformity assessment.
- Incident Reporting: Report actively exploited vulnerabilities within 24 hours; full details within 72 hours.
Distributor and Importer Responsibilities
You're not off the hook just because you didn't build it:
- Verify the manufacturer has completed conformity assessment.
- Check for CE marking and required documentation.
- Ensure products aren't modified in ways that affect compliance.
- Cooperate with market surveillance authorities.
- Report suspected non-compliance to the manufacturer and authorities.
Open Source Maintainer Considerations
The FOSS exception protects most community-driven projects. But you need to evaluate:
- Are you providing commercial support or services around this project?
- Is your project integrated into a commercial product by your employer?
- Do you accept payment for features or prioritized bug fixes?
If you answer "yes" to any of these, you may have manufacturer obligations for your contributions.
Implementation Guidance
Step 1: Map Your Organization's Roles
Create a table listing every product your organization makes available in the EU. For each product, identify:
- Who designed it?
- Who manufactures it (if hardware)?
- Who first places it on the EU market?
- Is it integrated into a larger commercial product?
Most software vendors will land in the "manufacturer" category. If you're reselling or white-labeling someone else's product, you might be a distributor or importer.
Step 2: Assess FOSS Exception Eligibility
For open source projects your team maintains:
- Is the project developed outside of commercial activity? (Contributed on personal time, no employer claims?)
- Is the project supplied outside of commercial activity? (No paid support contracts, no commercial licensing?)
- Does your employer sell products that incorporate this project?
If you're maintaining the project as part of your job, or if your employer's commercial products depend on it, you likely don't qualify for the FOSS exception.
Step 3: Inventory Your Obligations
Once you know your role, list the specific CRA requirements that apply. The OpenSSF's "Grow CRA Readiness" resource provides role-specific checklists. Use them.
For manufacturers, prioritize:
- Vulnerability disclosure policy (do you have one? is it public?)
- Secure development practices documentation
- Supply chain security (SBOM generation, dependency tracking)
- Incident response procedures
Step 4: Identify Gaps
Compare your current practices against CRA requirements. Common gaps we're seeing:
- No formal vulnerability handling process
- Missing SBOM generation in build pipeline
- Inadequate security documentation for end users
- No process for substantial modification assessment
Common Pitfalls
Assuming the FOSS Exception Applies Too Broadly: If you're paid to maintain a project, or if your employer's revenue depends on it, you probably can't claim the exception. Consult legal counsel before making this call.
Treating All Products the Same: The CRA has different requirements for "important" and "critical" products (Annex III). If you're building identity management systems, VPNs, or network firewalls, you'll face third-party conformity assessment.
Ignoring Substantial Modifications: If you customize a vendor's product for EU customers, you may become the manufacturer for compliance purposes. Document what you change and whether it affects security requirements.
Waiting for Competitors to Move First: 66% of organizations aren't familiar with the CRA. Being early gives you a competitive advantage and reduces last-minute compliance costs.
Confusing CRA with NIS2 or GDPR: These regulations overlap but have different scopes and requirements. CRA focuses on product security; NIS2 addresses operational resilience; GDPR governs data protection. You may need to comply with all three.
EU Cyber Resilience Act Overview
Quick Reference Table
| Role | Primary Obligations | Key Deliverables | Timeline |
|---|---|---|---|
| Manufacturer | Risk assessment, secure development, vulnerability handling, conformity assessment | Technical documentation, EU declaration of conformity, CE marking | Full compliance by September 11, 2026 |
| Importer | Verify manufacturer compliance, ensure documentation availability | Compliance verification records, contact information | September 11, 2026 |
| Distributor | Verify CE marking, store documentation, report non-compliance | Storage of manufacturer documentation | September 11, 2026 |
| OSS Steward | Voluntary security practices, coordinated disclosure | Security policy, vulnerability reporting process | Not mandatory, but recommended |
What to Do Monday Morning
- Schedule a 60-minute meeting with product, legal, and security teams.
- List every product you make available in the EU.
- Assign a CRA role to each product.
- Document which products qualify for FOSS exception (if any).
- Review the OpenSSF CRA Readiness resources for your specific role.
- Start building your gap analysis spreadsheet.
You've got 24 months. That sounds like a lot, but conformity assessment for complex products takes time. Start mapping your roles now, before you're racing to meet the deadline.
