EU Cyber Resilience Act compliance hinges on infrastructure identity

At a glance

What this is: This is an analysis of how the EU Cyber Resilience Act turns infrastructure identity, access, encryption, and audit into compliance-critical controls.

Why it matters: It matters because IAM, NHI, PAM, and platform teams now shape whether digital products can meet CRA outcomes for least privilege, traceability, and blast-radius reduction.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Teleport's analysis of CRA compliance through infrastructure identity

Context

The CRA makes infrastructure identity a compliance issue, not just an internal security design choice. If products ship with digital elements, the question is no longer whether access is convenient, but whether every connection is cryptographically bound, least-privileged, auditable, and resistant to reuse after compromise.

Teleport’s article is useful because it reframes CRA readiness around the control plane that most programmes treat as plumbing. That is the right starting point for IAM, NHI, PAM, and platform owners: if identity, access, and audit are fragmented across tools, the product may satisfy policy in theory while failing the operational test in practice.

Key questions

Q: How should security teams make CRA compliance part of identity architecture?

A: They should treat identity, authorization, device trust, encryption, and audit as one architecture question rather than separate controls. If those functions are split across disconnected tools, the programme cannot prove consistent enforcement or containment. The practical test is whether one identity plane can govern access, produce evidence, and limit blast radius across products and sessions.

Q: Why do static credentials create problems for CRA-aligned infrastructure?

A: Static credentials keep access alive after the task, which directly conflicts with the CRA’s push for unique, cryptographic identity and reduced reuse after compromise. A leaked key or token becomes a durable attack asset if it can be replayed across systems. That is why long-lived secrets should be treated as compliance risk, not just operational debt.

Q: What do teams get wrong about audit evidence for CRA readiness?

A: They often collect logs without correlating them to identity and access decisions. CRA-oriented evidence needs to show who authenticated, what privilege was granted, which device was used, and what action followed in one connected chain. Without that linkage, audit remains incomplete even if the individual systems are logging correctly.

Q: Who should own CRA identity controls across product and platform teams?

A: Ownership should sit with the team that governs access architecture, usually IAM, platform security, or identity engineering, with product security as a partner. The reason is simple: CRA outcomes depend on how access is issued, constrained, observed, and revoked. If no single team owns that lifecycle, the control design will stay fragmented.

Technical breakdown

Why the CRA turns infrastructure identity into a control plane

The CRA’s essential requirements land where infrastructure decides who or what can connect, what it can reach, and what gets recorded. Identity, authorization, device trust, encryption, and audit are not separate policy topics here. They are one control plane that determines whether a vulnerability becomes exploitable. The article correctly shows that the compliance problem is architectural: if access depends on static secrets, separate VPNs, or disjoint log streams, the product cannot prove consistent enforcement across sessions, protocols, and devices. Practical implication: treat infrastructure identity as a regulated control surface, not a tooling layer.

Practical implication: map CRA obligations to the infrastructure identity layer and test whether one control plane enforces them consistently.

How static credentials break CRA-aligned access models

Static credentials create the exact persistence the CRA seeks to eliminate. A leaked SSH key, database password, or API token remains usable until someone rotates it, and that delay extends the attack window far beyond the original compromise. The article’s point is not just that secrets are risky, but that long-lived credentials undermine the CRA’s expectation that compromise of one component should not open unrelated systems. Short-lived certificates, explicit grants, and identity-bound sessions reduce this exposure because the credential becomes less reusable as an attack asset. Practical implication: any environment still relying on durable secrets should be treated as structurally misaligned with CRA intent.

Practical implication: inventory long-lived secrets first, then replace the highest-risk ones with short-lived, identity-bound access.

Why unified audit trails matter for CRA evidence

CRA compliance is not only about preventing misuse. It is also about proving what happened, where, and through which identity path. When VPN, SSH, database, and cloud logs live in separate systems, incident reconstruction becomes partial and slow. Unified audit is therefore a control, not an afterthought, because it connects identity proof, access grants, session activity, and downstream actions into one evidence chain. The article’s architecture example shows the difference between scattered logging and an identity-linked record that can support incident analysis, forensic review, and regulatory evidence. Practical implication: audit design should start with identity correlation, not with log volume.

Practical implication: build identity-linked audit trails that join authentication, authorization, session use, and resource activity.

Threat narrative

Attacker objective: The objective was to turn a trusted security tool into a credential harvesting and reuse channel that expanded access across pipeline-connected infrastructure.

1. Entry occurred through a compromised Trivy version running inside thousands of CI/CD pipelines, where the tool’s trusted position gave attackers a path into credential-bearing workflows.
2. Credential access followed when SSH keys, Kubernetes secrets, and cloud tokens available to those pipelines were exposed and harvested from the compromised execution environment.
3. Impact came when the attacker retained access long enough to exfiltrate newly rotated secrets, showing that remediation windows were still too slow for the trust relationships in place.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CRA readiness is really infrastructure identity readiness. The article is right to place identity, access, encryption, and audit at the centre of CRA compliance. Those are the controls that decide whether a product can enforce least privilege, prove activity, and contain blast radius when something goes wrong. For practitioners, the implication is that CRA work belongs in the identity architecture programme, not as a late-stage compliance overlay.

Static credentials are now a regulatory liability pattern, not just a hygiene issue. The CRA’s intent clashes directly with durable SSH keys, shared secrets, and tokens that outlive the task they were meant to serve. This is especially true where CI/CD, admin access, and machine identity overlap, because one reused secret can cross multiple trust boundaries. The implication is that long-lived credential dependence must be treated as evidence of architectural non-compliance.

Fragmented security toolchains create evidence gaps that the CRA cannot tolerate. Separate VPN, PAM, SSH, and SIEM systems produce disjointed identity records that are hard to correlate after the fact. That breaks the enforcement story even when individual controls look present. The implication is that auditability must be designed as a single identity chain of custody across users, devices, services, and sessions.

Unified audit is becoming the minimum viable proof of control. The article shows that compliance depends on being able to answer who accessed what, from where, under which identity, and with what privilege at the point of use. That is not a logging problem alone. The implication is that programme owners should treat correlated audit as a first-class outcome of identity governance.

Infrastructure identity is where CRA, IAM, and NHI governance converge. The same patterns that weaken product compliance also weaken non-human identity governance: static credentials, excessive privilege, and poor offboarding. This is where human IAM habits fail to scale into machine and workload access. The implication is that teams should stop separating product compliance from identity governance maturity.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader breach pattern view, the The 52 NHI breaches Report shows how identity exposure repeatedly turns into operational compromise.

What this signals

CRA implementation will expose the weakest identity layer first: if your environment still depends on durable secrets, you are likely to fail the product-security test before you fail the paperwork test. The immediate signal for practitioners is to shift CRA planning into the same backlog as IAM modernisation, workload identity, and secrets reduction.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, the same architectural debt also undermines CRA-ready infrastructure. The gap is not a missing feature. It is a governance model still built around credentials that outlive the work they authorise.

Identity chain of custody: this is the control concept that will matter most as CRA evidence matures. Teams that can correlate device trust, session privilege, and audit trail in one flow will be better placed to answer both regulator questions and incident-response questions without rebuilding the story from fragments.

For practitioners

• Map CRA obligations to identity control points Trace every Annex I obligation back to the infrastructure layer that enforces identity, authorization, encryption, device trust, and audit. Use the map to identify where current controls are split across separate tools or teams.
• Eliminate durable secrets from product and pipeline paths Prioritise SSH keys, service account passwords, API tokens, and CI/CD credentials that can survive beyond a single task. Replace them with short-lived certificates or equivalent ephemeral identity where the product architecture allows it.
• Unify identity-linked audit evidence Correlate authentication, authorization, session, and resource events into one record that survives across SSH, database, cloud, and admin workflows. The aim is a single traceable identity chain, not a pile of disconnected logs.
• Test blast-radius containment with realistic compromise scenarios Simulate what happens when one infrastructure credential is stolen and measure how far the attacker can move before the access expires or is revoked. Use the exercise to expose where standing privilege still survives.

Key takeaways

• The CRA shifts identity, access, and audit from supporting controls to core compliance evidence.
• Static credentials, fragmented logs, and separate security tools all weaken the product assurance story the CRA expects.
• IAM, NHI, PAM, and platform teams should treat infrastructure identity as the control surface that determines whether CRA obligations are actually enforceable.

Key terms

• Infrastructure Identity: Infrastructure identity is the set of mechanisms that prove who or what is connecting to systems and what it is allowed to do. In practice, it combines authentication, authorization, device trust, and audit so access decisions are cryptographically grounded and traceable across sessions.
• Static Credential: A static credential is a long-lived secret such as an SSH key, token, or password that remains valid until someone manually changes it. It is operationally convenient but structurally risky because compromise can persist well beyond the original access need.
• Identity-linked Audit Trail: An identity-linked audit trail connects authentication, access grant, session activity, and resource actions into one evidence chain. It is more useful than isolated logs because it shows not just that an event happened, but which identity path made it possible.
• Blast Radius: Blast radius is the amount of additional access, systems, or data an attacker can reach after one identity or credential is compromised. Identity governance aims to shrink that radius through least privilege, short-lived access, and explicit boundaries between trust zones.

What's in the full article

Teleport's full article covers the operational detail this post intentionally leaves for the source:

• A line-by-line explanation of which CRA Annex I requirements map to identity, access, encryption, and audit controls.
• The before-and-after infrastructure examples showing how short-lived certificates replace static credentials in practice.
• The ENISA Secure by Design and Default Playbook references that expand the CRA discussion into implementation detail.
• The product and platform architecture guidance for teams deciding how to unify authentication, authorization, and audit.

👉 Teleport's full article covers the CRA control mapping, ENISA guidance, and before-and-after infrastructure examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.