CRA Compliance for Hardware Startups — A Practical Guide
CRA Compliance for Hardware Startups — A Practical Guide
Updated: June 2026
If you’re building hardware for the EU market, the Cyber Resilience Act is coming for you.
Already here, actually.
The CRA entered into force on 11 December 2024, with requirements rolling out in phases. The first major deadline — reporting obligations for manufacturers — hits 11 September 2026. That’s about three months away if you’re reading this in June.
Most hardware startups I talk to have heard the name but haven’t dug into what it actually means for their product.
This guide covers what matters for hardware companies. Not the full text of the regulation, but the practical bits you need to act on.
What Is the CRA?
The EU Cyber Resilience Act sets cybersecurity requirements for products with digital elements. That’s a broad category. Basically anything that connects, processes data, or runs software.
The goal: stop selling insecure products into the EU market.
The mechanism: mandatory security-by-design, vulnerability handling, and documentation. Products that don’t comply can’t get CE marking. Without CE marking, they can’t be sold in the EU.
That’s a problem if your FPGA-based product serves European customers.
Does It Apply to Your Product?
Short version: probably.
You need to check if your product falls into one of these categories:
- Default class — Most digital products. Self-declaration of conformity.
- Class I — Products with higher security risk (firewalls, VPNs, password managers, network management). Third-party assessment needed.
- Class II — Products with significant security implications (secure logins, digital certificates, intrusion detection). Full conformity assessment by a notified body.
Most hardware will be default class. That’s good — self-declaration is simpler.
But here’s where it gets interesting for hardware engineers:
- An FPGA accelerator card with a management interface? Digital element.
- An ASIC with embedded firmware? Digital element.
- An IoT controller running bare metal? Digital element.
Even if your product is fundamentally hardware, if it has any software, firmware, or configurable logic that processes data — it’s in scope.
Key Deadlines
| Deadline | What Happens |
|---|---|
| 11 Dec 2024 | CRA entered into force |
| 11 Sep 2026 | Reporting obligations for manufacturers apply (Article 14) |
| 11 Dec 2027 | Full application — all products must comply for CE marking |
The September 2026 deadline is the one to watch. From that date, manufacturers must report actively exploited vulnerabilities and incidents to ENISA within 24 hours (for critical products) or 72 hours. That means your vulnerability handling process needs to be operational before September — not something you can set up overnight.
What You Actually Need to Do
1. Security-by-Design
Not a checkbox. You need to demonstrate that security was considered from the start.
For hardware, this means:
- Threat modelling early in the design phase
- Secure boot and firmware update mechanisms
- Access control on debug interfaces (JTAG, serial consoles)
- Side-channel resistance where relevant
- Cryptographic acceleration for secure communications
Document your decisions. “We skipped this because the threat model showed it wasn’t needed” is fine. “We didn’t think about it” isn’t.
2. Vulnerability Handling
You need a process for receiving, triaging, and fixing security vulnerabilities. This doesn’t have to be complex — for a startup, a dedicated email address and a response SLA might be enough.
What matters:
- Clear reporting channel ([email protected])
- Internal triage process
- Patch timelines (default class has specific requirements: 14 days for critical fixes)
- Public disclosure coordination
This is the one that becomes mandatory on 11 September 2026. If you’re selling into the EU, your vulnerability process needs to be live before that date.
3. Technical Documentation
This is where most startups trip up. The CRA requires technical documentation that demonstrates compliance.
You need:
- System architecture — Block diagrams, interface definitions, data flow
- Security analysis — Threat model, risk assessment, mitigations
- Design documentation — How you implemented security controls
- Supply chain — Third-party IP, open-source components, their versions
- Test results — Security testing, penetration testing (proportionate to risk)
The trick: do this as you go, not the night before. Documenting six months of design decisions after the fact is painful.
4. CE Marking
The CRA ties into existing CE marking requirements. Your product needs:
- Declaration of conformity
- Technical documentation package (see above)
- Product labelling with contact info
- Instruction and safety information
Without this, customs can hold your products at the border.
What This Means for Startups
First, the bad news: compliance takes time and effort.
The good news: it’s achievable. And with the September 2026 deadline approaching, early movers have a real advantage — most of your competitors haven’t started yet.
Some practical tips:
Start documentation now. Create a compliance folder in your project repo. Drop architecture diagrams, security decisions, and supply chain info in there as you go. Future you will be grateful.
Map your supply chain. Every open-source component, every third-party IP block, every purchased module. You need to know what’s in your product and where it came from. Also need to verify that your OS and third-party components meet their own CRA obligations.
Think about updates. Your product needs to receive security updates for a defined period (typically 5-10 years depending on product category). That affects architecture decisions now.
Don’t over-engineer. Proportionate security. A sensor node with a 10-minute battery life doesn’t need the same security controls as a network router. Document your risk assessment honestly.
How Daxzio Can Help
I work with FPGA and ASIC startups on verification and design. CRA compliance overlaps with both.
What I can help with:
- Reviewing your design for security architecture gaps
- Documentation frameworks that don’t suck
- Third-party IP supply chain analysis
- Testing strategies that cover security scenarios
- Connecting you with notified bodies when you need formal assessment
Not everything needs a consultant. But if you’re not sure whether your product is in scope, or you’re facing a compliance deadline and don’t know where to start — it’s cheaper than getting it wrong.
The CRA isn’t going away. The September 2026 deadline is three months away. And the earlier you build for it, the less painful it’ll be.
Questions? [Get in touch](/contact). Happy to have a chat about where your product sits.
*Last updated: June 2026. Regulations change — verify requirements with a qualified assessor for your specific product.*