Implement SSH 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.

CRA Annex I emphasizes authenticated access, role separation, and auditable control mechanisms. Certificate-based SSH directly addresses these objectives by providing short-lived, identity-bound credentials with enforced usage policies and traceability.

Manufacturers and operators adopting Public Key Infrastructure (PKI) and certificate-based SSH can demonstrate active control over administrative interfaces, reduce the risk of unauthorized access, and align with CRA requirements for secure access control and monitoring.

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 Certificate-based SSH 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.

SSH Certificate-Based Authentication

SSH certificates allow for strong, identity-based access controls using short-lived, signed authentication credentials instead of static keys or passwords. They work by having a Certificate Authority (CA) sign a public SSH key and bind it to an identity, with restrictions such as:

Login permissions
Validity duration (i.e., certificate expiration)
Command restrictions
Hostnames or IPs allowed

Unlike static key-based authentication, which has no expiration, no revocation, and is unmanaged, SSH certificates offer central control, lifecycle enforcement, and fine-grained policy.

A basic SSH certificate flow looks like this:

A user or service generates a public/private key pair.
The public key is submitted to a centralized signing authority (typically integrated into a workflow or identity provider).
The CA issues a signed SSH certificate that is valid for a limited time and usage scope.
The user presents the certificate when accessing a device or system.
The system validates the certificate against the CA’s public key and enforces restrictions.

SSH certificates eliminate the need to pre-distribute public keys across all systems and ensure every login can be traced back to a verified identity, within a defined time window, with logged activity.

Least Privilege with SSH Certificates

SSH certificates aren’t just about authentication; they also enable precise authorization. Here’s how they enforce least privilege:

Role-Based Access Control: Certificates can be issued with principals (e.g., admin, deploy, readonly) that map directly to system roles or user groups.
Command Restrictions: Certificates can include a force-command option that limits what the user can do after logging in. For example, even if a certificate allows SSH access, the system can restrict the user to running a single script or command — not a full shell.
Host Restrictions: Certificates can be scoped to specific systems or IP ranges, ensuring users can’t use one certificate to hop laterally across an environment.
Time-Bound Access: Since SSH certificates are short-lived (minutes to hours), even elevated privileges are temporary and can’t be reused later.
No Shared Credentials: Every user has their own identity-bound certificate, eliminating shared accounts and reducing insider threat risk.
Policy Enforcement at Issuance: A centralized CA can enforce who gets access to what, when, and under what conditions — preventing over-privileged access at the source.

CRA Annex I Relevance

CRA Annex I Part I Clause	Verbatim Text	SSH Certificate Relevance
(1)	Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.	✅ Certificate-based access limits lateral movement risk and closes common administrative attack paths.
(2)(d)	Ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems.	✅ SSH certificates enforce identity-bound access with short lifespans, and enable fine-grained controls such as per-user roles, command restrictions, and host limitations — all key to enforcing least privilege.
(2)(f)	Protect the integrity of stored, transmitted or otherwise processed data, personal or other...	✅ SSH certificates enforce verified identities, reducing spoofing and misuse of static credentials that might alter sensitive configurations.
(2)(j)	Be designed, developed and produced to limit attack surfaces, including external interfaces.	✅ Replacing shared keys or passwords with short-lived certificates removes persistent attack vectors.
(2)(l)	Provide security related information by recording and monitoring relevant internal activity...	✅ SSH logins using certificates can be tied back to an individual identity with time-bound precision. This enhances audit logs and access transparency.

SSH Certificates: A CRA-Ready Approach

SSH is widely used to manage systems, but the way it is traditionally deployed, using static public/private key pairs, is misaligned with the intent of the EU Cyber Resilience Act (CRA).

Why traditional SSH keys fall short:

No expiration – Keys remain valid indefinitely unless rotated manually.
No identity binding – Keys are anonymous blobs of data, not tied to a verified user or device.
No policy controls – Cannot be limited to specific commands, IP ranges, or time windows.
No revocation – Once distributed, a key works until it is manually removed from every authorized system.
Difficult to audit – Hard to attribute actions back to individuals or roles.

This static and unmanaged nature creates hidden risks that undermine both security operations and CRA requirements for traceability, revocation, and controlled access.

SSH certificates as the solution:

By introducing certificate-based SSH, these limitations disappear. Certificates allow access policies to be enforced dynamically at login, rather than relying on static provisioning. Expiration, revocation, and policy rules are embedded into the certificate itself. This makes SSH certificates:

Time-bound and automatically expiring
Bound to verified user or device identities
Enforceable with fine-grained policies
Auditable and aligned with Zero Trust principles

In short, SSH certificates transform SSH into a CRA-ready access solution, combining strong cryptography with the operational controls regulators expect.

EJBCA Makes SSH Certificates Practical at Scale

Rolling out SSH certificates across a large fleet requires automation and centralized control. EJBCA provides the PKI backbone to operationalize this model:

Automated short-lived certificates – Instead of static keys, EJBCA issues SSH certificates valid for only minutes or hours. Credentials expire naturally, removing the need for manual rotation.
Identity-bound logins – Every certificate is tied to a known user or system identity, making it possible to attribute access and activity to the right entity.
No static key sprawl – With certificates validated against a trusted CA, there’s no need to distribute and maintain public key files on every server.
Built-in audit trail – All issuance and revocation requests are logged centrally, creating a traceable record that supports CRA requirements.
Seamless integration – Certificate issuance can be triggered from ITSM tools, CI/CD pipelines, or orchestration platforms, fitting into existing engineering workflows.

In practice, this means SSH certificate-based access can be rolled out across thousands of nodes with the same automation, control, and visibility already used for TLS or code-signing certificates—making it both secure and production-ready.

Conclusion

Although the EU Cyber Resilience Act (CRA) does not explicitly require SSH certificates, they represent a highly effective method for meeting several of its Essential Cybersecurity Requirements, particularly those related to authentication, identity management, and least privilege access.

SSH certificate-based authentication offers a practical, standards-aligned path forward. By replacing static, unmanaged SSH keys with short-lived, signed credentials issued by a trusted Certificate Authority (CA), organizations can implement strong, policy-driven access controls that:

Bind identities to access events
Limit privilege and duration
Reduce the attack surface
Enable centralized audit and revocation

This approach positions manufacturers and operators to demonstrate clear alignment with the CRA's intent, even before Harmonized Standards are finalized.

Keyfactor's EJBCA PKI platform, designed for scalability, control, and visibility, helps facilitate this transition. With policy enforcement, logging, and integration with existing workflows, SSH certificate-based access can become a key part of CRA-aligned cybersecurity practices.

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