Why mTLS is the Recommended Authentication Architecture for EU Cyber Resilience Act Compliance

Executive Summary

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") entered into force on 10 December 2024. Its essential cybersecurity requirements, set out in Annex I, apply in full to products placed on the market from 11 December 2027. Importantly, vulnerability reporting and incident notification obligations under Article 14 apply from 11 September 2026 — meaning manufacturer obligations are already phasing in.

The CRA's Annex I, Part I requirements directly shape how IoT device authentication must be designed. Products must be placed on the market without unauthorized access vulnerabilities arising from default or shared credentials, must provide unique per-device authentication secrets generated in accordance with cryptographic best practices, and must allow device owners to change or revoke credentials if a device is compromised.

This article explains why mutual TLS (mTLS) with X.509 certificates is the authentication architecture best aligned with these requirements for IoT devices, and why common token-based approaches — OAuth2, JWT, and Personal Access Tokens (PAT) — carry significant CRA compliance risk as typically implemented in IoT deployments. Compliance is always determined through a manufacturer's cybersecurity risk assessment under Article 13(2); this document is intended to support that analysis, not substitute for it.

CRA Applicability Timeline

Manufacturers should be aware that the CRA does not have a single compliance date.

Teams with hardware design cycles of 18–24 months who are not already planning for December 2027 are already behind. Teams that have not yet reviewed their Article 14 vulnerability disclosure processes have less than twelve months before those obligations become enforceable.

What the CRA Requires for Authentication

The CRA's essential cybersecurity requirements relevant to device authentication are set out in Annex I, Part I. The specific provisions that bear on authentication design are:

Annex I, Part I, §(1)(b): Products must be placed on the market without unauthorized access arising from default or shared authentication values. Where passwords or authentication secrets exist, they must not use regularities, common strings, MAC addresses, or manufacturer-identifiable patterns. Each device's secret must be unique and generated according to cryptographic best practices.

Annex I, Part I, §(2)(b): Products must be placed on the market in a secure-by-default configuration, including the ability to reset to a secure original state.

Annex I, Part I, §(2)(d): Products must ensure protection from unauthorized access through appropriate control mechanisms, including authentication, identity, and access management systems, and must report on possible unauthorized access.

Annex I, Part II, §(5): Products must address vulnerabilities without delay, including through security updates. This includes the ability to revoke compromised credentials.

Important note on scope: The CRA does not enumerate or prohibit specific authentication technologies. Compliance is assessed through the risk assessment framework of Article 13(2). The analysis below addresses how common authentication methods perform against the Annex I requirements under their typical IoT deployment patterns.

The Bootstrap Credential Problem

A critical issue that is frequently overlooked when evaluating OAuth2 and JWT for IoT: these methods require a credential to be embedded in or transmitted to the device before any token-based authentication can begin.

This is not a weakness in the standards themselves. OAuth2 and JWT were designed primarily for user authentication and server-to-server flows in HTTP environments. The problem arises when these methods are applied to IoT device identity, where the bootstrap credential becomes a persistent, device-side secret subject to the same CRA requirements as any other credential.

The fundamental issue is not that these methods are inherently insecure. The issue is that, as typically deployed in IoT, they relocate the compliance risk rather than eliminate it: the hardcoded password is replaced by a hardcoded client secret, signing key, or static token. The Annex I, Part I, §(1)(b) requirement — that each device have a unique, cryptographically generated secret that cannot be shared or replicated — is not satisfied by provisioning a different credential of the same structural type.

Why Token-Based Methods Carry High CRA Risk in IoT

OAuth2

The OAuth 2.0 specification (RFC 6749) was designed for delegated authorization over HTTP. The specification explicitly notes that use over protocols other than HTTP is out of scope. For IoT devices operating over MQTT, CoAP, or constrained networks, this creates immediate friction.

The Annex I compliance risk in typical IoT deployment is as follows:

A deployment using OAuth2 with dynamic client registration (RFC 7591) and per-device asymmetric key pairs, where private keys are generated on-device and never transmitted, can substantially reduce this risk. However, at that point the architecture is functionally equivalent to PKI provisioning, and the question becomes whether the added complexity of token issuance delivers sufficient benefit over mTLS directly.

JWT

JSON Web Tokens (RFC 7519) are bearer tokens signed with a private key or a shared secret. The CRA risk profile in IoT deployment:

JWTs where each device has an asymmetric key pair generated on-device (e.g., within a TPM) and where the signing key never leaves the hardware can satisfy Annex I, Part I, §(1)(b). However, the bearer-token vulnerability and limited revocation control remain residual risks that require additional architectural controls.

Personal Access Tokens

PATs are static, long-lived credentials by design. They are user-centric (issued per user account, not per device), require manual rotation, and provide limited per-device revocation granularity. In the context of device identity at scale, PATs represent the highest CRA risk profile of the three token-based methods discussed here.

Why mTLS with X.509 Certificates Is Architecturally Different

mTLS addresses the bootstrap credential problem at the architecture level rather than through operational controls.

The Key Insight: Private Keys Generated On-Device

During manufacturing, the following provisioning sequence eliminates the need to transmit any secret material:

MANUFACTURING LINE
──────────────────────────────────────────────────────────
 1. Device generates unique key pair (ideally in HSM/TPM)
 2. Device creates Certificate Signing Request (CSR)
    → Only the PUBLIC key leaves the device
 3. Manufacturing CA signs CSR → Device Certificate
 4. Certificate + CA chain stored in secure storage
 5. Device serial number → Certificate serial number mapping recorded

 ⚠  CRITICAL: Private key NEVER leaves the device
──────────────────────────────────────────────────────────

This is structurally different from OAuth2 client credential provisioning, where the client_secret must be created server-side and transmitted to the device. In the mTLS model, there is no shared secret to transmit, intercept, or clone.

Alignment with Annex I Requirements

Cryptographic Proof of Possession

The fundamental security advantage of mTLS is that the device proves possession of the private key through a challenge-response handshake — the key itself is never transmitted. During a TLS handshake:

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

Even if an attacker captures every byte of network traffic across the lifetime of the device, they cannot reconstruct the private key. In contrast, an OAuth2 client_secret or a JWT signing key, if extracted from device memory, immediately enables impersonation.

Hardware Security Module Integration

X.509 private keys can be generated and stored within Hardware Security Modules (HSM) or Trusted Platform Modules (TPM). When combined with HSM/TPM-backed key generation:

• The private key is generated within secure silicon and cannot be exported in any form

• Cryptographic operations (signing the CertificateVerify message during TLS handshake) execute inside the chip

• Even with full physical access to the device, the private key cannot be extracted

Note that hardware-backed key storage also benefits other credential types: a unique device secret stored in a TPM with no extraction path significantly reduces cloning risk. However, the bearer-token vulnerability of JWT and the rotation limitations of PATs remain even when hardware storage is used.

Certificate Lifecycle Management

Comparative Analysis

The table below assesses each authentication approach against the Annex I requirements most relevant to device identity. Ratings reflect typical IoT deployment patterns. Implementations that deviate significantly from these patterns — for example, OAuth2 with on-device asymmetric key generation via dynamic client registration — may have a materially different compliance risk profile and should be assessed individually under Article 13(2).

Legend:
✅ = Fully supported
⚠️ = Partial / implementation-dependent
❌ = Not supported or high risk in typical deployment

Recommendations

For Product Development Teams

1. Implement on-device key generation at manufacturing. Integrate key pair generation and CSR creation into your production line, preferably with HSM/TPM-based key generation where private keys are created within secure silicon and cannot be extracted.

2. Deploy a PKI infrastructure with CLM. Establish a certificate authority hierarchy capable of issuing, renewing, and revoking device certificates at scale. Plan for automated renewal well before certificate expiry to avoid authentication disruptions.

3. Configure all backend endpoints for mTLS. Ensure API endpoints and cloud connectivity gateways require and validate client certificates, including CRL/OCSP checking.

4. Plan for Article 14 obligations now. Vulnerability handling and incident reporting obligations apply from 11 September 2026. Establish your coordinated vulnerability disclosure policy and notification processes before that date.

For Compliance Officers

1. Document your authentication architecture against Annex I. CRA conformity assessment evidence must demonstrate how your device authentication design satisfies Annex I, Part I, §(1)(b) and §(2)(d). Specifically document that no secrets are transmitted during provisioning and that per-device revocation is possible.

2. Maintain certificate issuance records. The mapping between device serial numbers and certificate serial numbers is an operational security requirement and a potential conformity assessment evidence item.

3. Establish and test revocation procedures. Document how compromised devices will be identified, how their certificates will be revoked, and how quickly revocation propagates to all validating endpoints.

4. Review the Commission's CRA Implementation Guidance. The European Commission published implementing guidance in December 2025 that provides authoritative interpretation of key Annex I requirements. Compliance assessments should be grounded in that guidance alongside the regulation text.

Conclusion

The CRA's Annex I requirements do not prohibit any specific authentication technology. They require that device authentication be designed such that each device has a unique, cryptographically generated credential that cannot be shared, extracted and replayed, or cloned — and that compromised devices can be individually revoked.

Token-based methods like OAuth2, JWT, and PAT, as typically deployed in IoT, carry significant compliance risk against these requirements because their standard deployment patterns require a credential to be provisioned to the device before any token can be obtained. That bootstrap credential is subject to the same Annex I requirements as any other device secret — and most current deployments do not satisfy those requirements.

Implementations of these methods that use per-device asymmetric key pairs generated on-device (effectively rebuilding a PKI provisioning flow) can reduce the compliance risk. At that point, the architectural question is whether the added complexity of token issuance delivers sufficient benefit relative to using mTLS directly.

mTLS with X.509 certificates is the authentication architecture that most directly satisfies the Annex I requirements for IoT device identity. Private keys generated on-device and protected by hardware never need to exist anywhere else. Authentication is cryptographic proof of possession, not transmission of a secret. Revocation is immediate and per-device. Mutual authentication protects both directions of the connection.

Organizations developing IoT products for the EU market should begin PKI infrastructure planning and manufacturing integration now. With hardware design cycles of 18–24 months and Article 14 obligations active from 11 September 2026, the time available to architect and implement compliant authentication is shorter than the December 2027 product deadline suggests.

References

• EU Regulation 2024/2847 (Cyber Resilience Act), OJ L, 20.11.2024

• CRA Annex I, Part I: Essential Cybersecurity Requirements (Product Design)

• CRA Annex I, Part II: Essential Cybersecurity Requirements (Vulnerability Handling)

• CRA Article 13(2): Cybersecurity Risk Assessment Obligation

• CRA Article 14: Vulnerability and Incident Reporting Obligations

• CRA Article 64: Penalties

• CRA Article 71: Entry Into Force and Applicability Dates

• European Commission CRA Implementation Guidance (December 2025)

• ETSI EN 303 645: Cyber Security for Consumer IoT

• IEEE 802.1AR: Secure Device Identity (IDevID)

• RFC 6749: The OAuth 2.0 Authorization Framework

• RFC 7519: JSON Web Token (JWT)

• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol

• RFC 5246: Transport Layer Security (TLS) Protocol

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

• prEN 40000-1-2 (Draft): CRA horizontal cybersecurity standard — product requirements

• prEN 40000-1-3 (Draft): CRA horizontal cybersecurity standard — vulnerability handling