TL;DR: Teleport says EU Cyber Resilience Act compliance now hinges on infrastructure identity, because Annex I obligations on access control, encryption, auditability, and blast-radius reduction are enforced by architecture rather than by isolated tools. Static credentials, fragmented logs, and detached VPN or PAM layers turn compliance into an integrity problem, not just a documentation exercise.
At a glance
What this is: This article argues that CRA readiness depends on infrastructure identity, with unified access control, encryption, and audit providing the practical route to meeting Annex I obligations.
Why it matters: It matters because IAM, PAM, and platform teams now need evidence that access is cryptographically bound, short-lived, and auditable across the full infrastructure stack.
By the numbers:
- Full enforcement begins in December 2027, and non-compliance carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.
👉 Read Teleport's analysis of EU Cyber Resilience Act compliance and infrastructure identity
Context
The core CRA problem is not just secure software, but whether the infrastructure around that software can prove who or what is connecting, what it can reach, and how that access is recorded. In this article, infrastructure identity is the control layer that turns legal requirements into enforceable technical outcomes.
Telemetry frames the Cyber Resilience Act as an architectural compliance issue because the regulation’s Annex I requirements map to access control, encryption, audit, and blast-radius containment. That makes identity, not only vulnerability management, a material part of product security for anything shipped with digital elements.
Key questions
Q: What breaks when CRA infrastructure still relies on static credentials?
A: Static credentials undermine the CRA because they can be reused across systems long after the original task ends. That makes compromise persistent rather than bounded, and it breaks the assumption that access is unique, time-limited, and revocable. In practice, reusable secrets turn a local exposure into an infrastructure-wide compliance failure.
Q: Why do fragmented VPN, PAM, and vault tools create CRA risk?
A: Fragmented tools split the identity story across multiple logs, policies, and credential lifecycles. That makes it harder to prove who accessed what, harder to contain a compromise, and harder to show that monitoring is complete. The CRA expects the access path itself to produce evidence, not for analysts to assemble it after the fact.
Q: How can teams tell whether infrastructure identity is actually meeting CRA expectations?
A: A strong signal is that every privileged connection is issued as a short-lived, device-bound identity, logged in one place, and automatically expires without leaving standing access. If teams still need to reconcile separate SSH, VPN, database, and PAM records to answer basic questions, the control model is not yet CRA-ready.
Q: What is the difference between compliance logging and CRA-grade auditability?
A: Compliance logging records events, but CRA-grade auditability lets teams reconstruct identity, authorization, device trust, and resource use in one trace. The difference is operational: one produces partial evidence, while the other provides a complete chain of custody for access decisions. That is what makes the record useful for containment and assurance.
Technical breakdown
Why static credentials fail CRA access control
The CRA’s access-control language assumes that each connection can be tied to a unique, verifiable identity. Static SSH keys, shared passwords, and long-lived API tokens break that assumption because they can be reused long after the original session or task ends. When credentials outlive the intended access window, compromise of one secret becomes compromise of multiple systems, which is exactly the kind of failure the CRA tries to prevent through unique cryptographic identity and explicit authorization.
Practical implication: replace reusable infrastructure credentials with short-lived identities that are issued per session and expire automatically.
How fragmented tools weaken auditability and blast-radius control
The CRA requires monitoring and incident-impact reduction, but a stack split across VPNs, SSH tools, PAM, vaults, and SIEM pipelines produces disconnected evidence. Each tool can log its own events, yet none of them has the full identity chain across authentication, authorization, and resource use. That makes forensics slow and weakens containment because operators cannot quickly trace what was accessed, by whom, and under which policy grant.
Practical implication: build a unified audit trail that correlates identity, session, and resource events across every access path.
What CRA-ready infrastructure identity looks like
CRA-ready infrastructure ties identity to device posture, authorization, encryption, and monitoring in one flow. The article’s model uses hardware-backed trust, mutual TLS, deny-by-default policy, and short-lived certificates so that access exists only for the task at hand. That approach reduces attack surface and enforces the CRA’s expectation that compromise of one component should not automatically expose adjacent systems or persist beyond the session.
Practical implication: align access policy, device attestation, and certificate issuance so that every privileged connection is both ephemeral and fully recorded.
Threat narrative
Attacker objective: The objective is to harvest trusted infrastructure credentials and use them to reach additional systems before defenders can fully revoke the exposed secrets.
- Entry begins when attackers compromise a widely deployed security tool and use it as a credential harvester inside CI/CD pipelines.
- Credential access expands as SSH keys, Kubernetes secrets, and cloud tokens exposed through the compromised pipeline are reused before rotation closes the window.
- Impact follows when retained secrets enable further access to infrastructure and demonstrate how trusted tooling can become a high-value credential path.
Breaches seen in the wild
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Infrastructure identity has become the compliance boundary for CRA readiness. The regulation’s Annex I requirements are not satisfied by adding more security tools around the stack. They are satisfied when identity, encryption, audit, and containment are enforced at the layer where infrastructure decisions are made. For practitioners, that means CRA work belongs in IAM and platform architecture, not only in product security documentation.
Static credentials are now a regulatory liability, not just an operational smell. The article shows why shared secrets, long-lived SSH keys, and inherited access paths conflict with the CRA’s expectation of unique cryptographic identity and minimal privilege. Once a secret can be reused across systems or survive beyond a task, the control model no longer matches the regulation’s intent. Practitioners should treat secret lifetime and reuse as compliance issues.
Unified auditability is the control that turns access into evidence. The CRA and ENISA guidance both point to monitoring that can explain who accessed what, from where, and under which policy. Fragmented logs across VPN, PAM, and database tools do not deliver that outcome. The field should stop treating logging as a collection feature and start treating it as an architectural property of the access path.
Identity blast radius is the named concept this article sharpens. The compliance question is not only whether access exists, but how far one compromised credential can travel before containment stops it. CRA-ready environments must make compromise local rather than systemic. That is the practical benchmark for any infrastructure identity programme now being positioned as compliance infrastructure.
The CRA aligns governance and engineering more tightly than many teams expect. ENISA’s implementation guidance makes the legal text operational by translating broad obligations into architecture-level requirements. This narrows the gap between policy and evidence, which is useful for auditors but demanding for teams still relying on disconnected access systems. Practitioners should expect governance to move closer to runtime identity controls.
From our research library:
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Read next: Identity Security Programme Guide
What this signals
Identity blast radius is the operational question that CRA programmes now need to answer. If a single compromised secret can reach multiple systems, the organisation has not reduced impact in the way the regulation expects. Teams should therefore measure whether a privileged connection can be tied to one task, one device, and one auditable policy grant.
Static access patterns are where CRA evidence will fail first. Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey. That makes secret lifetime, not just secret storage, a board-level compliance concern.
From Teleport’s analysis, infrastructure identity is now a governance discipline, not a tooling preference. The programme question is whether access control, encryption, and audit can be proven as one control plane across the product lifecycle. If they cannot, the compliance gap is architectural rather than procedural.
For practitioners
- Replace static infrastructure credentials Eliminate reusable SSH keys, shared passwords, and long-lived tokens for infrastructure access, then issue short-lived cryptographic identities for each session or task.
- Unify access and audit telemetry Correlate authentication, authorization, session recording, and resource access into one exportable audit trail so that reviewers can reconstruct every privileged action.
- Bind privileged access to device trust Require hardware-backed device attestation before elevated access is granted, and make the certificate or session expire when the task ends.
- Limit blast radius by design Scope each grant to a specific resource, time window, and role so that compromise of one identity does not automatically expose adjacent infrastructure.
Key takeaways
- The article frames CRA compliance as an infrastructure identity problem, not only a secure coding or patching problem.
- Static secrets, fragmented access paths, and disconnected logs make it difficult to prove the control outcomes the CRA expects.
- Teams that want CRA-ready evidence need ephemeral identity, device trust, and a unified audit trail across privileged access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, NIST CSF 2.0 sets the technical controls, and EU Cyber Resilience Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on limiting access scope for infrastructure identities and denying standing privilege. |
| NHI-07 — Long-Lived Secrets | Static SSH keys, passwords, and tokens are the article’s clearest compliance failure mode. | |
| NHI-01 — Improper Offboarding | The article emphasises revocation and expiry so compromised or outdated access cannot persist. | |
| Recommendation — Scope infrastructure identities to the minimum resources and duration needed for each session. Replace long-lived infrastructure secrets with short-lived certificates and automatic expiry. Revoke stale infrastructure identities promptly and ensure expired access cannot be reused. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CRA-ready access depends on explicit, auditable authorisation and least-privilege permissions. |
| PR.DS-11 — Data at Rest Protected | The article directly ties CRA compliance to encryption for stored and transmitted data. | |
| DE.CM-01 — Network and Environmental Monitoring | The article requires continuous monitoring and a unified audit trail across access paths. | |
| Recommendation — Define and enforce explicit entitlements for each privileged access path. Ensure infrastructure data is encrypted in transit and at rest by default. Centralise monitoring so privileged activity is recorded and correlated across all infrastructure layers. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The Trivy compromise shows credential harvesting followed by reuse across connected systems. |
| Recommendation — Map exposed secrets to credential access and lateral movement paths in detection engineering. | ||
| EU Cyber Resilience Act | Annex I — Essential Requirements | Annex I is the regulation’s core technical requirement set, and the article maps infrastructure identity to it. |
| Recommendation — Translate Annex I obligations into identity, encryption, and audit controls for the product environment. | ||
Key terms
- Infrastructure Identity: Infrastructure identity is the set of credentials and trust relationships that allow systems, workloads, and automation to authenticate to other systems. It is the machine-facing layer of identity governance, and it often carries more operational risk than human access because it is persistent and widely reused.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Unified audit trail: A single evidence stream that links identity proofing, authentication, consent, and executed actions across human and non-human actors. It matters because split logs prevent teams from reconstructing what the agent was allowed to do and what it actually did.
- Short-Lived Cryptographic Identity: A short-lived cryptographic identity is a temporary digital identity that exists for a limited time and then expires automatically. It is usually represented by a certificate, token, or key pair with a narrow validity window, reducing exposure if compromised and supporting ephemeral access for workloads, agents, and automated processes.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- The article’s full breakdown of CRA Annex I obligations mapped to infrastructure identity controls
- The before-and-after access flow showing how short-lived certificates change privileged database access
- The detailed comparison between fragmented VPN, PAM, and vault stacks versus a unified identity layer
- The compliance context around ENISA’s Security by Design and Default Playbook and how it sharpens CRA interpretation
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.
Published by the NHIMG editorial team on July 1, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org