The EU Cyber Resilience Act (CRA) changes everything – and your current approach probably won’t cut it.
Remember when “admin/admin” was an acceptable default password?
Those days are officially over.
The EU Cyber Resilience Act (CRA) entered into force in December 2024. If you’re shipping IoT products to Europe, this isn’t optional—it’s the law.
And here’s what most teams are missing: your OAuth2 tokens, JWTs, and API keys probably won’t pass compliance.
The Problem Nobody’s Talking About
The CRA doesn’t just ban weak passwords. It prohibits any shared or hardcoded credentials across your device fleet.
That client secret embedded in your firmware? Non-compliant.
That API key provisioned to every device? Non-compliant.
That JWT signing key shared across your product line? Non-compliant.
The regulation requires every device to have its own unique, cryptographically secure identity. And owners must be able to revoke credentials if a device is compromised.
Violations carry penalties up to €15 million or 2.5% of global revenue.
The Bootstrap Credential Problem
Here’s what OAuth2 and JWT advocates often overlook: you need a hardcoded credential to get the token in the first place.
Think about it:
OAuth2 Client Credentials flow requires your device to store a client_id and client_secret to request an access token. Those are static values burned into firmware—exactly what the CRA prohibits.
JWT authentication requires the device to possess a private signing key to generate tokens. That key must be provisioned somehow. If it’s the same key across your fleet, you’ve violated unique-device requirements. If you’re provisioning unique keys per device, congratulations—you’re building PKI infrastructure anyway.
API Keys and PATs are static strings embedded in the device by definition.
The uncomfortable truth? These methods just replace one hardcoded secret (a password) with another hardcoded secret (a client secret, signing key, or token). You haven’t solved the CRA compliance problem—you’ve repackaged it.
Why mTLS Is Fundamentally Different
Mutual TLS with X.509 certificates solves the bootstrap problem entirely.
Here’s the key insight: the private key can be generated on the device itself and never needs to exist anywhere else.
During manufacturing, the device generates its own key pair internally—ideally within a hardware security module where the private key literally cannot be extracted. The device sends only a Certificate Signing Request (containing the public key) to your CA. The signed certificate comes back. Done.
No shared secrets. No credentials to hardcode. No sensitive material transmitted during provisioning.
Compare that to OAuth2, where your client secret must be created server-side and then somehow securely transferred to every device in your fleet.
What mTLS delivers:
✅ Every device gets a unique certificate with its own key pair
✅ Private keys never leave the device—ever
✅ No hardcoded secrets in firmware
✅ Individual device revocation via certificate revocation lists
✅ Mutual authentication—device verifies server, server verifies device
AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all recommend X.509 certificate authentication for exactly these reasons.
What This Means For Your Roadmap
By December 2027, your devices must comply. That sounds far away, but consider:
-
Hardware design cycles run 18-24 months
-
PKI infrastructure takes time to architect
-
Manufacturing needs certificate provisioning integration
-
Your backend needs mTLS support
The teams starting now will have a competitive advantage. The teams that wait will scramble to retrofit security into products never designed for it.
The Bottom Line
The CRA isn’t asking you to choose a better hardcoded credential. It’s asking you to eliminate hardcoded credentials entirely.
OAuth2 and JWT weren’t designed for this world. They solve user authentication problems brilliantly. But for device identity under CRA requirements, they just move the compliance violation from one place to another.
mTLS with X.509 certificates is architecturally different. It’s the only approach where sensitive credentials never need to be shared, transmitted, or hardcoded.
The companies that understand this distinction now will build compliant products. The ones that don’t will be retrofitting—or exiting the EU market.
No matter where you are in your security journey, our experts are here to help. Book a demo to tell us more about your organization and your goals.
