Why mTLS is the Superior Authentication Method for EU Cyber Resilience Act Compliance

Executive Summary

The EU Cyber Resilience Act (CRA), which entered into force on 10 December 2024 with full enforcement beginning 11 December 2027, fundamentally changes how IoT devices must handle authentication. The regulation explicitly prohibits hardcoded and default credentials while mandating unique device-level authentication.

The EU CRA Authentication Requirements

What the CRA Mandates

The CRA establishes essential cybersecurity requirements in Annex I that directly impact authentication design:

1. Prohibition of Default/Shared Credentials: The regulation forbids all users of a device type from sharing the same password or authentication secrets. Each device must have its own unique credentials.

2. Unique Device Identity: Each device must have its own dedicated secret (certificate, key, etc.) created according to cryptographic best practices. Passwords must not contain regularities, common strings, MAC addresses, or manufacturer-identifiable patterns.

3. Secure-by-Default Configuration: Products must be placed on the market with secure default configurations, with the ability to reset to a secure original state.

4. Protection from Unauthorized Access: Devices must ensure protection through appropriate control mechanisms, including authentication, identity, and access management systems.

5. Credential Changeability: Device owners must be able to change secrets if the device is compromised.

The Hardcoded Credentials Problem

The CRA explicitly targets a long-standing industry malpractice: manufacturers hardcoding default login/password parameters (often "admin/admin") without requiring users to change them. This practice is now forbidden by law in the EU.

Why Even Unique Device Secrets Fail Without Cryptographic Proof

A common misconception is that assigning a unique secret (API key, token, or password) to each device during manufacturing satisfies the CRA's requirements. It does not.

Here's why: Any credential that must be transmitted to prove identity can be intercepted, extracted, or cloned.

Consider a device with a unique API key:

1. Extraction vulnerability: The secret must be stored somewhere on the device (flash memory, EEPROM, configuration file). An attacker with physical access can extract it through JTAG, firmware dumps, or memory analysis.

2. Transmission vulnerability: Every time the device authenticates, it sends the secret over the network. Even with TLS encryption, the secret exists in plaintext in device memory before transmission and on the server after receipt.

3. Cloning attack: Once extracted, the secret can be used on any other device or system. The server cannot distinguish between the legitimate device and a clone using the same credential.

4. No proof of device identity: Possessing a secret proves only that someone knows the secret—not that they are the authorized device. There is no cryptographic binding between the credential and the physical hardware.

The CRA requires protection from unauthorized access—but a system where credentials can be extracted and replayed on unauthorized devices fails this requirement.

What Actually Solves This Problem

True device identity requires cryptographic proof of possession without transmitting the secret itself:

The distinction is critical: mTLS and TPM-based authentication prove the device possesses a secret without ever exposing that secret. The private key participates in a challenge-response handshake but is never transmitted. Even if an attacker intercepts every byte of network traffic, they cannot clone the device's identity.

This is why the CRA's requirements implicitly demand asymmetric cryptography with hardware-protected keys—anything less leaves credentials vulnerable to extraction and replay.

Why Token-Based Authentication Methods Fail CRA Compliance

The Bootstrap Credential Problem

A critical issue often overlooked by OAuth2 and JWT advocates: these methods require a hardcoded credential to obtain the token in the first place.

The fundamental problem: These authentication methods don't eliminate hardcoded credentials—they simply replace one hardcoded secret (a password) with another hardcoded secret (a client secret, signing key, or token). The CRA compliance violation is repackaged, not resolved.

If you're provisioning unique JWT signing keys per device to satisfy the CRA's unique-credential requirement, you've essentially built a PKI infrastructure. At that point, the question becomes: why not use mTLS directly and gain all its additional security benefits?

OAuth2 Limitations for IoT

Key Problems:

• Static Client Secrets: OAuth2 requires a client secret embedded within the application to request access tokens. This is a static value that cannot be considered secure—if an attacker reverse engineers it, they can construct fake devices that appear authentic to the authorization flow.

• Not Designed for IoT: The OAuth specification explicitly states it was designed for HTTP protocol use cases. Constrained IoT devices acting without human interaction are not covered by the OAuth specification.

• Token Theft Risk: When the path between client and resource server traverses constrained networks, access tokens transmitted could be stolen, requiring complex modifications to standard OAuth flows.

JWT Limitations for IoT

Key Problems:

• Bootstrap Key Required: To generate a JWT, the device must possess a private signing key. This key must be provisioned somehow—either shared across the fleet (violating unique-credential requirements) or unique per device (which means you've built PKI infrastructure).

• Bearer Token Vulnerability: JWTs are bearer tokens—anyone possessing the token can use it. If leaked from a device, they pose significant security risks.

• Clock Dependency: JWT validation requires accurate timekeeping. An attack on the time service of a device opens opportunities for replay attacks and token manipulation.

• Token Renewal Complexity: For embedded devices, token renewal typically requires MQTT reconnection. There is no standard mechanism for in-session token renewal, leading to connection disruptions.

Personal Access Token (PAT) Limitations

Key Problems:

• Static Embedding: PATs are fundamentally static credentials that must be hardcoded into device firmware or configuration—exactly what the CRA prohibits.

• Rotation Challenges: PATs require manual regeneration and redistribution, making fleet-wide rotation operationally impractical.

• User-Centric Design: PATs were designed for user authentication scenarios, not machine-to-machine device identity.

Why mTLS with X.509 Certificates Satisfies CRA Requirements

Solving the Bootstrap Problem

mTLS with X.509 certificates is architecturally different from token-based methods because the private key can be generated on the device itself and never needs to exist anywhere else.

During manufacturing:

1. The device generates its own key pair internally—ideally within an HSM/TPM where the private key cannot be extracted

2. The device creates a Certificate Signing Request (CSR) containing only the public key

3. The manufacturing CA signs the CSR and returns the certificate

4. The private key never leaves the device; no shared secret is ever transmitted

Compare this to OAuth2: The client secret must be created server-side and then securely transferred to every device in your fleet. That transfer is the compliance violation.

Complete Alignment with CRA Annex I

Technical Advantages

1. Asymmetric Cryptography Eliminates Shared Secrets

mTLS uses public-private key pairs where the private key never leaves the device. This is fundamentally different from OAuth client secrets, JWTs, or PATs where a credential must be transmitted or embedded.

Token-Based Auth (OAuth2/JWT/PAT):
┌────────────────────────────────────────────────────────────┐
│  Server creates secret → Secret transferred to device      │
│                          (Transmission = vulnerability)    │
└────────────────────────────────────────────────────────────┘

mTLS Authentication:
┌────────────────────────────────────────────────────────────┐
│  Device generates private key (never leaves device)        │
│  Device sends CSR with PUBLIC key only                     │
│  CA returns signed certificate                             │
│                          (No secret ever transmitted)      │
└────────────────────────────────────────────────────────────┘

2. Hardware Security Module Integration

X.509 certificates can be generated and stored within Hardware Security Modules (HSM) or Trusted Platform Modules (TPM), ensuring cryptographic material never exists in extractable form. The private key is generated within secure silicon and cannot be exported.

3. Certificate Chain of Trust

mTLS establishes a hierarchical trust model:

• Root CA Certificate: Trust anchor for the organization

• Intermediate CA Certificate: Operational signing authority

• Device Certificate: Unique identity per device

This chain enables scalable provisioning—manufacturers can sign devices into a cryptographic chain of trust during manufacturing without exposing root CA private keys.

4. Built-In Revocation Mechanisms

When a device is compromised, its certificate serial number can be added to a Certificate Revocation List. All servers validating against the CRL immediately reject the compromised device—no firmware update required.

5. Mutual Authentication

mTLS validates both the server and client simultaneously:

1. Device presents its certificate to the API endpoint

2. Server validates certificate against trusted CA chain

3. Server presents its certificate to the device

4. Device validates server identity

This bidirectional verification prevents man-in-the-middle attacks and ensures devices only communicate with legitimate backend services.

Implementation Architecture for CRA Compliance

Manufacturing Phase

┌──────────────────────────────────────────────────────────────┐
│                    MANUFACTURING LINE                        │
├──────────────────────────────────────────────────────────────┤
│  1. Device generates unique key pair (ideally in HSM/TPM)    │
│  2. Device creates Certificate Signing Request (CSR)         │
│     → Only PUBLIC key leaves the device                      │
│  3. Manufacturing CA signs CSR → Device Certificate          │
│  4. Certificate + CA chain burned to secure storage          │
│  5. Device serial number → Certificate mapping recorded      │
│                                                              │
│  ⚠️  CRITICAL: Private key NEVER leaves the device           │
└──────────────────────────────────────────────────────────────┘

Runtime Authentication Flow

┌─────────┐                              ┌─────────────┐
│   IoT   │                              │     API     │
│ Device  │                              │  Endpoint   │
└────┬────┘                              └──────┬──────┘
     │                                          │
     │  1. TLS ClientHello                      │
     │ ────────────────────────────────────────►│
     │                                          │
     │  2. ServerHello + Server Certificate     │
     │ ◄────────────────────────────────────────│
     │                                          │
     │  3. Device validates server cert chain   │
     │                                          │
     │  4. Client Certificate + Verify          │
     │ ────────────────────────────────────────►│
     │                                          │
     │  5. Server validates device cert chain   │
     │     + Checks CRL/OCSP                    │
     │                                          │
     │  6. Encrypted session established        │
     │ ◄───────────────────────────────────────►│
     │                                          │

Certificate Lifecycle Management

Comparative Analysis Summary

Legend: ✅ = Fully Supported | ⚠️ = Partial/Complex | ❌ = Not Supported

Recommendations

For Product Development Teams

1. Implement X.509 certificate provisioning in manufacturing: Integrate certificate generation into your production line, preferably with HSM/TPM-based key generation where private keys are created on-device.

2. Deploy PKI infrastructure: Establish a certificate authority hierarchy to issue, renew, and revoke device certificates at scale.

3. Configure API endpoints for mTLS: Ensure all backend services require and validate client certificates.

4. Implement automated certificate lifecycle management: Plan for certificate renewal before the December 2027 enforcement deadline.

For Compliance Officers

1. Document your authentication architecture: CRA conformity assessments require evidence of how your devices satisfy Annex I requirements. Specifically document that no secrets are transmitted during provisioning.

2. Maintain certificate issuance records: Track the mapping between device serial numbers and certificate serial numbers.

3. Establish revocation procedures: Document how compromised devices will be identified and their certificates revoked.

Conclusion

The EU Cyber Resilience Act represents a fundamental shift in IoT security requirements. The CRA isn't asking manufacturers to choose a better hardcoded credential—it's requiring the elimination of hardcoded credentials entirely.

Token-based authentication methods like OAuth2, JWT, and PAT cannot satisfy this requirement because they fundamentally depend on a bootstrap credential (client secret, signing key, or token) that must be embedded in or transmitted to the device. They repackage the compliance problem rather than solving it.

mTLS with X.509 certificates is architecturally different and is the only authentication mechanism that:

• Provides cryptographically unique identity per device

• Eliminates hardcoded shared secrets entirely

• Requires no bootstrap credential—private keys are generated on-device

• Proves device identity through cryptographic challenge-response without transmitting secrets

• Resists extraction and cloning attacks when combined with HSM/TPM

• Enables individual device revocation

• Supports hardware-based key protection

• Delivers mutual authentication to prevent spoofing

Simply assigning unique secrets to each device is not sufficient—if those secrets can be extracted and replayed, the device identity can be cloned, violating the CRA's unauthorized access protections.

Organizations developing IoT products for the EU market must transition to certificate-based authentication before the December 2027 enforcement date to achieve CRA compliance and avoid penalties of up to €15 million or 2.5% of global annual turnover.

References

• EU Regulation 2024/2847 (Cyber Resilience Act)

• CRA Annex I: Essential Cybersecurity Requirements

• ETSI EN 303 645: Cyber Security for Consumer IoT

• IEEE 802.1AR: Secure Device Identity (IDevID)

• RFC 5246: Transport Layer Security (TLS) Protocol

• RFC 5280: X.509 PKI Certificate and CRL Profile