The EU Cyber Resilience Act (CRA) is the most significant product security regulation in a decade. Adopted in October 2024 with enforcement beginning in 2027, it mandates that every product with digital elements sold in the EU must meet baseline cybersecurity requirements — including cryptographic protections for data, communications, firmware updates, and device identity.
For manufacturers, this means PKI isn’t optional. You need firmware signing infrastructure, device certificate provisioning, secure update channels, and vulnerability management processes — all documented and auditable. Products that don’t comply can’t carry the CE mark and can’t be sold in the EU.
What the CRA Covers
The CRA applies to products with digital elements — any software or hardware product with a network connection or data processing capability:
| Category | Examples | CRA Class |
|---|---|---|
| Default (self-assessment) | Smart TVs, toys, fitness trackers, basic IoT | Class Default |
| Important Class I | Routers, firewalls, OS, password managers, VPNs | Class I (third-party assessment) |
| Important Class II | Hypervisors, HSMs, smart meters, industrial controllers | Class II (third-party assessment) |
| Critical | Smart cards, hardware security modules, secure elements | Critical (EU certification) |
What’s Excluded
- Open-source software (non-commercial)
- SaaS/cloud services (covered by NIS2 instead)
- Medical devices (covered by MDR)
- Automotive (covered by UNECE)
- Aviation (covered by EASA)
CRA Cryptographic Requirements
Annex I: Essential Cybersecurity Requirements
The CRA’s Annex I defines security requirements that directly involve cryptography:
| Requirement | Cryptographic Implication |
|---|---|
| Protect confidentiality of data | Encryption at rest and in transit (TLS, AES) |
| Protect integrity of data | Digital signatures, MACs, hash verification |
| Protect availability | Resilient key management, CA redundancy |
| Minimize attack surface | Disable unused crypto, remove hardcoded keys |
| Secure by default | Strong crypto enabled out of the box |
| Protect against unauthorized access | Certificate-based device authentication |
| Ensure secure communications | TLS 1.2+ with approved cipher suites |
| Ensure secure updates | Signed firmware, verified update channel |
| Allow factory reset | Secure key destruction on reset |
Secure Update Requirements (Article 10)
Device Identity Requirements
Products must be uniquely identifiable and authenticatable:
| Requirement | Implementation |
|---|---|
| Unique device identity | Device certificate with unique serial/CN |
| Authentication to services | mTLS or certificate-based auth |
| Prevent impersonation | PKI-based identity, not shared secrets |
| Secure provisioning | Certificate enrollment during manufacturing |
| Identity lifecycle | Certificate renewal, revocation capability |
PKI Architecture for CRA Compliance
Manufacturer PKI Infrastructure
Firmware Signing Pipeline
# Firmware signing in CI/CD (simplified)
# 1. Build firmware
make firmware BOARD=product-v2
# 2. Sign with manufacturer's code signing key (HSM-backed)
cosign sign-blob --yes \
--key "pkcs11:token=manufacturer-hsm;object=firmware-signing-key" \
--output-signature firmware-v2.1.sig \
--output-certificate firmware-v2.1.crt \
./build/firmware-v2.1.bin
# 3. Create update manifest (signed)
cat > manifest.json << EOF
{
"version": "2.1.0",
"firmware": "firmware-v2.1.bin",
"signature": "firmware-v2.1.sig",
"certificate": "firmware-v2.1.crt",
"sha256": "$(sha256sum ./build/firmware-v2.1.bin | cut -d' ' -f1)",
"min_version": "2.0.0",
"release_date": "2026-05-11"
}
EOF
# 4. Sign the manifest itself
cosign sign-blob --yes \
--key "pkcs11:token=manufacturer-hsm;object=firmware-signing-key" \
--output-signature manifest.sig \
./manifest.json
# 5. Upload to update server (TLS-protected)
aws s3 cp ./build/ s3://firmware-updates/product-v2/2.1.0/ --recursiveDevice Certificate Provisioning
# Factory provisioning script (runs during manufacturing)
import ssl
from cryptography import x509
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import ec
def provision_device(device_serial: str, device_ca_key, device_ca_cert):
"""Generate and install device certificate during manufacturing."""
# Generate device key pair (on device or in secure element)
device_key = ec.generate_private_key(ec.SECP256R1())
# Create CSR
csr = x509.CertificateSigningRequestBuilder().subject_name(
x509.Name([
x509.NameAttribute(x509.oid.NameOID.COMMON_NAME, f"device-{device_serial}"),
x509.NameAttribute(x509.oid.NameOID.ORGANIZATION_NAME, "Acme Products"),
x509.NameAttribute(x509.oid.NameOID.SERIAL_NUMBER, device_serial),
])
).sign(device_key, hashes.SHA256())
# Sign with Device CA
cert = x509.CertificateBuilder().subject_name(
csr.subject
).issuer_name(
device_ca_cert.subject
).public_key(
csr.public_key()
).serial_number(
x509.random_serial_number()
).not_valid_before(datetime.utcnow()
).not_valid_after(datetime.utcnow() + timedelta(days=3650) # 10-year device life
).add_extension(
x509.SubjectAlternativeName([
x509.UniformResourceIdentifier(f"urn:device:{device_serial}")
]), critical=False
).add_extension(
x509.ExtendedKeyUsage([
x509.oid.ExtendedKeyUsageOID.CLIENT_AUTH
]), critical=True
).sign(device_ca_key, hashes.SHA256())
# Install on device (via JTAG, serial, or secure provisioning interface)
install_certificate(device_serial, cert, device_key)
install_trust_store(device_serial, [manufacturer_root_cert])
return cert.serial_numberVulnerability Management (Article 11)
The CRA requires manufacturers to handle vulnerabilities in their products for at least 5 years:
| Requirement | Crypto Relevance |
|---|---|
| Identify and document vulnerabilities | Track crypto library versions (OpenSSL, mbedTLS) |
| Provide security updates without delay | Signed firmware update infrastructure |
| Coordinate vulnerability disclosure | CVE process for crypto vulnerabilities |
| Maintain SBOM | Include crypto libraries in Software Bill of Materials |
| Report actively exploited vulnerabilities | 24-hour notification to ENISA for crypto exploits |
Crypto-Specific Vulnerability Scenarios
| Scenario | CRA Response Required |
|---|---|
| OpenSSL CVE in your product | Patch and push signed update within “without undue delay” |
| Algorithm deprecated (e.g., SHA-1) | Update product to use approved algorithm |
| Key compromise | Revoke affected certificates, re-provision devices |
| Protocol vulnerability (e.g., TLS downgrade) | Firmware update disabling vulnerable protocol |
| Quantum threat to product keys | Migration plan to PQC algorithms |
Timeline and Enforcement
| Date | Milestone |
|---|---|
| October 2024 | CRA adopted (published in Official Journal) |
| September 2026 | Reporting obligations begin (vulnerability reporting to ENISA) |
| December 2027 | Full enforcement (products must comply for CE marking) |
| Ongoing | Market surveillance authorities can withdraw non-compliant products |
Penalties
| Violation | Maximum Fine |
|---|---|
| Non-compliance with essential requirements | €15 million or 2.5% of global turnover |
| Non-compliance with other obligations | €10 million or 2% of global turnover |
| Incorrect/incomplete information to authorities | €5 million or 1% of global turnover |
CRA vs Other Product Security Regulations
| Aspect | EU CRA | US Cyber Trust Mark | UK PSTI Act | ETSI EN 303 645 |
|---|---|---|---|---|
| Scope | All products with digital elements | Consumer IoT (voluntary) | Consumer IoT | Consumer IoT |
| Mandatory | Yes (CE marking) | No (voluntary label) | Yes | Referenced standard |
| Crypto requirements | Comprehensive | Basic | Basic (no default passwords) | Moderate |
| Firmware signing | Required | Recommended | Not specified | Recommended |
| Update support | 5 years minimum | Not specified | Reasonable period | Not specified |
| SBOM | Required | Not required | Not required | Not required |
| Penalties | Up to €15M / 2.5% | N/A | Up to £10M | N/A |
Implementation Roadmap for Manufacturers
Phase 1: Assessment (Months 1-3)
- Classify your products (Default, Class I, Class II, Critical)
- Inventory existing cryptographic controls
- Gap analysis against Annex I requirements
- Identify crypto libraries in use (SBOM)
Phase 2: PKI Infrastructure (Months 3-6)
- Establish manufacturer root CA (HSM-protected)
- Deploy firmware signing infrastructure
- Set up device certificate provisioning for manufacturing line
- Implement secure update server with TLS
Phase 3: Product Updates (Months 6-12)
- Implement firmware signature verification in products
- Add certificate-based device identity
- Enable secure boot chain
- Deploy OTA update mechanism with signature verification
Phase 4: Processes (Months 12-18)
- Establish vulnerability disclosure process
- Set up crypto library monitoring (CVE tracking)
- Document conformity assessment evidence
- Train development teams on secure-by-design
FAQ
Q: Does the CRA apply to software-only products?
Yes. The CRA covers both hardware and software products with digital elements. A desktop application, mobile app, or firmware that processes data or connects to a network is in scope. Pure SaaS (no downloadable component) is excluded — it falls under NIS2 instead.
Q: What crypto algorithms does the CRA require?
The CRA doesn’t prescribe specific algorithms. It requires “state of the art” cryptographic mechanisms appropriate to the risk. In practice, reference ENISA recommendations and NIST standards: AES-128+, RSA-2048+, ECDSA P-256+, TLS 1.2+, SHA-256+. Avoid deprecated algorithms (MD5, SHA-1, DES, RC4).
Q: Do I need to sign firmware updates?
Yes. Annex I requires that updates are delivered securely and that their integrity and authenticity can be verified. Digital signatures on firmware packages (code signing) are the standard mechanism. The device must verify the signature before installing the update.
Q: How long must I provide security updates?
At least 5 years from placing the product on the market, or the expected product lifetime — whichever is longer. For a router with a 10-year expected life, you must provide security updates for 10 years.
Q: Does the CRA require device certificates?
Not explicitly by name, but the requirements for unique device identity, authentication, and secure communication effectively mandate certificate-based identity for connected products. Shared secrets and hardcoded credentials are explicitly prohibited.
Q: How does the CRA affect open-source software?
Non-commercial open-source is excluded. But if you incorporate open-source components into a commercial product, you’re responsible for their security — including cryptographic vulnerabilities. Track open-source crypto libraries in your SBOM and patch when CVEs are published.
Related Reading: