Implement Operational Certificates for CRA

In the context of the EU Cyber Resilience Act (CRA), ensuring device integrity from the earliest stage of operation is a critical cybersecurity objective. Annex I of the CRA outlines essential requirements that all products must meet regardless of classification. While detailed harmonized standards are still under development (expected by September 2026), manufacturers are already under pressure to align product designs with CRA expectations ahead of the regulation’s enforcement in December 2027.

This guide explores how operational certificates, issued after strong device identity verification, can help manufacturers and operators meet critical objectives under the CRA. Operational certificates are a foundational building block for runtime device trust, enabling secure communications, access control, and system integrity checks. By extending trust beyond the point of manufacture into the operational environment, they provide a scalable, proven mechanism to support ongoing compliance.

This guide is intended for embedded engineers, product security teams, firmware developers, and compliance leads who are building or maintaining connected products intended for the European market. It is especially relevant to those responsible for security architecture and product lifecycle risk mitigation, including those preparing for conformity assessment under the CRA.

Disclaimer: This guide provides one possible interpretation of the Cyber Resilience Act (CRA) and outlines how enabling operational certificates may contribute to compliance efforts.

Keyfactor anticipates that forthcoming harmonized standards will align with this interpretation; however, at the time of writing, Keyfactor does not have direct involvement or firsthand insight into the development of those standards.

Operational Certificates

An operational certificate is a short-lived X.509 certificate issued to a device once its hardware identity, commonly verified via an IDevID or similar mechanism, is authenticated. Unlike the static, unchanging IDevID, operational certificates are meant to be rotated regularly and tied to the active security posture of the device.

These certificates are typically issued by the operator of the device, such as a service provider, enterprise, or system integrator. In some cases, the manufacturer may act as the operator, particularly in managed service or connected-product models. In other cases, the operator is an entirely separate entity managing devices in a specific environment or domain.

This separation reinforces the principle of delegated trust, where manufacturers embed foundational trust (e.g., IDevIDs), and operators enforce runtime trust appropriate for their security and operational policies.

These certificates are used to:

• Establish secure sessions (TLS, mTLS)

• Authenticate to services

• Sign logs or data outputs

• Authorize access to APIs or networks

• Participate in secure software updates

These certificates enable continuous assurance that the device is still behaving as expected and authorized to function.

The Operational Certificate Lifecycle

A robust operational certificate lifecycle typically includes the following stages:

1. Request
   The device presents its IDevID or proof of hardware origin to an operator-managed issuing authority (e.g., internal CA, registration service, or bootstrap server).

2. Enrollment
   Upon successful identity verification, the issuing authority provides an operational certificate signed by a trusted CA.

3. Use
   The certificate is installed on the device and used to authenticate, encrypt, and sign operational traffic.

4. Expiration
   The certificate has a short validity period (e.g., days to years) and must be replaced before it expires.

5. Rotation
   A new certificate is issued after re-verifying device status and, optionally, health or compliance posture.

6. Revocation
   If a device is compromised, disconnected, or decommissioned, the operational certificate is revoked to prevent misuse.

7. Audit
   All issuance, renewal, and revocation events are logged and can be tied back to the verified IDevID.

Why Rotation Matters

Certificate rotation is not just a hygiene practice—it’s a control. Frequent rotation ensures that:

• Devices stay within a valid trust boundary

• Keys are short-lived, limiting damage from leaks or compromise

• Misconfigured or rogue devices can be identified and quickly excluded

• Revoked devices can't continue operation with stale credentials

Rotation policies are often defined by the operator’s risk profile and compliance needs, not necessarily by the manufacturer. This ensures the certificate trust model is tailored to the environment the device operates in, rather than a generic one-size-fits-all model. In short, rotation limits dwell time and enforces continuous trust, not just one-time validation.

Operational Certificates and CRA Annex I

Operational certificates directly support the enforcement of CRA Annex I. The table below illustrates their relevance:

Trust Depends on Controlled Signing

Operational certificates are only as trustworthy as the infrastructure and processes that issue and rotate them. Secure issuance depends on:

• Validated identity (via IDevID or similar)

• Controlled access to issuing keys (e.g., via HSM)

• Trusted software used to verify identity and issue the certificate

• Logging and auditing of issuance, renewal, and revocation

All of these mechanisms are consistent with CRA Annex I clauses around secure design, access control, and tamper resistance.

How Keyfactor Helps

EJBCA supports operational certificate management as part of its PKI and device identity platforms. The platform supports this operational trust model by separating identity provisioning from runtime certificate issuance. Manufacturers can provision identity at the factory, while operators or service owners retain full control over the operational certificate lifecycle, including policy, issuance, and rotation schedules.

• Policy-based issuance: Only devices with a valid identity and attestation receive operational certificates.

• Lifecycle automation: Certificates can be rotated on schedule, on signal (e.g., reboot, config change), or via health checks.

• Revocation and blocking: Devices can be revoked or excluded in real time, reducing incident spread.

• Audit and compliance: Every issuance event is tied to the originating identity and stored in immutable logs.

With EJBCA:

• Certificates are short-lived and verifiable

• Rotation is automated and enforced

• Device behavior can be observable and traceable

• Trust boundaries are continuously maintained

• CRA compliance is supported with actionable controls

Conclusions

As connected products grow in complexity and regulation tightens under the EU Cyber Resilience Act (CRA), manufacturers and operators need to implement security measures that extend beyond static provisioning. Operational certificates play a pivotal role in meeting key objectives of CRA Annex I, enabling runtime trust, enforcing secure communication, and ensuring dynamic access control based on the current state of the device.

By adopting short-lived, policy-driven operational certificates tied to verified hardware identities, organizations can embed continuous assurance into their product lifecycle. This not only limits the window of exposure for compromised or misconfigured devices but also supports core CRA principles such as identity management, secure software updates, and traceability.

While harmonized standards are still evolving, operational certificate lifecycles, designed and enforced with tools like EJBCA, offer a practical, standards-aligned foundation for resilient products. EJBCA provides the PKI infrastructure to issue and manage both initial and operational device certificates, automate enrollment and renewal, and enforce policies for secure communication and access control. With integrated auditing and compliance reporting, EJBCA ensures that manufacturers can align engineering practices with CRA obligations from design through deployment.

Related Content

Complementary Solution Areas and Guides

• The EU CRA Requirements: Security and Compliance Across the Product Lifecycle - An engineering-focused summary of the CRA.

• Implementing Secure Boot for CRA - Validate firmware signatures at startup to ensure device integrity from the moment it powers on.

• Implementing Secure Firmware Updates for CRA - Sign firmware and software updates to guarantee authenticity and prevent tampering in the field.

• Implementing Initial Device Identities for CRA – Issue and manage identity certificates at manufacturing or first boot to establish strong device identity.

• Implementing SSH Certificates for CRA – Replace unmanaged SSH keys with certificate-based access, enforce security policies, and enable auditability.

Contact us

Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.

Request a Demo