TL;DR: Teleport argues that the EU Cyber Resilience Act and ENISA’s secure-by-design playbook push infrastructure away from static credentials, standing privilege, and after-the-fact auditing toward cryptographic identity, deny-by-default access, and lifecycle governance for human, machine, and AI workloads. The compliance shift is that identity must be proven in architecture, not reconstructed after the fact, because review-based models no longer match how modern infrastructure operates.
At a glance
What this is: This is a CRA-focused analysis of how secure-by-design requirements translate into identity controls for infrastructure and AI workloads, with cryptographic identity, deny-by-default access, and auditability as the central themes.
Why it matters: IAM, PAM, and NHI teams need to treat CRA alignment as an identity architecture problem because static credentials, standing privilege, and weak lifecycle governance now create both compliance and exposure gaps across human, machine, and AI actors.
👉 Read Teleport's analysis of CRA identity controls for AI workloads
Context
The EU Cyber Resilience Act is turning identity control from a policy preference into an architectural requirement. For infrastructure and AI workloads, that means the control plane must prove who or what is connecting, what it can reach, and whether access disappears when the task ends.
Teleport's article maps those expectations to ENISA's Secure by Design and Default Playbook, then ties them to concrete controls such as cryptographic identity, deny-by-default access, just-in-time privilege, auditability, and lifecycle governance. The primary governance gap is not whether teams can describe security intent, but whether the system enforces it continuously across human, machine, and agentic actors.
That distinction matters because CRA-style compliance is not satisfied by post-hoc review of static credentials or by assuming access can be certified later. The article's core argument is that secure-by-design now means identity proof, privilege scope, and audit evidence must exist at connection time, not after an incident or audit cycle.
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 standing privileges create a higher access management risk?
A: Standing privileges increase risk because they remain available outside the task that justified them. That widens the window for misuse, makes review less meaningful, and increases the chance that access survives organisational change. The longer privilege persists, the more likely it is to outlive the decision that created it.
Q: How do teams know whether identity controls are actually CRA-ready?
A: Identity controls are CRA-ready when the system can show who or what accessed a resource, under what grant, for how long, and with what approval or policy basis. If those answers depend on manual reconstruction from scattered logs, the control model is still too weak for secure-by-design expectations.
Q: How should security teams govern AI and workload identities at runtime?
A: Security teams should govern runtime identities by combining least privilege, continuous telemetry, and approval-gated containment. The goal is not just to issue credentials safely, but to detect when those credentials are being used in ways that increase blast radius. Runtime governance should include scoped permissions, event correlation, and clear escalation thresholds.
Technical breakdown
Cryptographic identity replaces static credentials
Static credentials such as SSH keys, API tokens, and shared passwords break the CRA's secure-by-design logic because they decouple identity from the session. Cryptographic identity binds the subject to the connection, typically through short-lived certificates, mTLS, or SPIFFE-compatible workload credentials. That design removes the assumption that a credential can be safely reused, rotated later, or audited after the fact. It also changes the trust model for AI workloads and automation, which often depend on secrets embedded in pipelines or service configurations. When identity is ephemeral and verifiable at issuance time, the attack surface becomes much smaller and the audit trail becomes meaningful.
Practical implication: Replace reusable secrets with short-lived, identity-bound credentials for workloads, pipelines, and AI services.
Deny-by-default access control and zero standing privilege
CRA-aligned access design starts from denial, not entitlement. Deny-by-default role controls force every user, service, or process to earn access explicitly, while zero standing privilege ensures elevated rights exist only for the duration of the task. This matters because standing access turns every compromise into an open-ended opportunity, whereas JIT access constrains the blast radius to a narrow session window. The architectural point is that least privilege is no longer just a policy statement; it must be enforceable by the access layer itself, including approval, expiry, and traceability. For non-human actors, that is often the difference between controlled automation and unmanaged privilege.
Practical implication: Move privileged access into JIT workflows with explicit expiry, owner approval, and deny-first policy enforcement.
Immutable audit trails make compliance provable
The CRA's emphasis on evidence means logging is not a back-office control, it is part of the product's security posture. Structured, tamper-resistant audit records capture authentication, session start and stop, privilege grants, and administrative actions in a way that supports investigation and compliance. This closes the gap between what teams believe happened and what the system can prove happened. For AI workloads, the issue becomes more acute because autonomous or semi-autonomous activity can change faster than human review cycles. Auditability therefore has to be designed into the access path, not bolted on through separate logging tools after the fact.
Practical implication: Centralise access events into a tamper-resistant audit trail that can support compliance, forensics, and AI activity review.
Threat narrative
Attacker objective: The objective is to turn a single stolen or leaked credential into persistent, hard-to-audit access across infrastructure and AI workloads.
- Entry begins when a human, service, or AI workload uses reusable static credentials that can be copied, leaked, or replayed outside the intended connection context.
- Escalation follows when those long-lived credentials are reused for broader infrastructure access, creating standing privilege that outlives the original task or approval.
- Impact occurs when unauthorized access persists across systems, enabling lateral movement, secret exposure, or unauditable changes that are hard to contain under CRA-style controls.
Breaches seen in the wild
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
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
CRA compliance is becoming an identity architecture test, not a documentation exercise. The article shows that the EU Cyber Resilience Act and ENISA guidance both assume security is built into defaults, not asserted in policy decks. That shifts the centre of gravity from audit narratives to enforceable access mechanics, which is exactly where IAM, PAM, and NHI governance converge. Practitioners should treat CRA readiness as a design question about how identity is issued, constrained, and revoked.
Static credentials are now a compliance liability because they undermine provable security-by-design. The problem is not only leakage risk, but the fact that reusable secrets make it impossible to prove who or what was connected at any given moment. That weakens every downstream control, from least privilege to incident reconstruction. The practical conclusion is that identity assurance must move to issuance time, not renewal time.
Zero standing privilege is the control pattern CRA-style infrastructure makes unavoidable. The article ties secure-by-design expectations to task-bound access that expires automatically, which is the opposite of persistent privilege. That matters across human administrators, service accounts, and AI workloads because the same standing-access assumption fails in all three cases. Teams should re-evaluate where long-lived access still exists simply because operations have accepted it as normal.
Agentic identity extends the same governance problem into AI workloads. The article's AI workload section makes clear that non-human actors inherit the same cryptographic identity, authorization, and audit expectations as other infrastructure actors. The difference is that AI workloads can invoke tools and services faster than human review cycles can react, so lifecycle assumptions break sooner. Practitioners should treat autonomous or semi-autonomous workloads as governed identities, not as application logic.
Unified access governance is the named concept CRA implementation keeps surfacing. Fragmented controls across SSH, databases, Kubernetes, cloud consoles, and AI services create enforcement gaps that secure-by-design requirements do not tolerate. A single policy and audit layer does not just simplify operations, it makes the compliance boundary legible. The lesson for identity programmes is that governance quality now depends on how much of the stack shares one control plane.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- 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: Just-in-Time Access and Zero Standing Privilege Guide
What this signals
Static credential debt is the clearest CRA readiness gap. If infrastructure still depends on reusable secrets, the system cannot prove identity at the moment of access, and that undermines secure-by-design claims before an auditor even asks for evidence. The shift is toward issuance-time control, not cleanup after the fact.
Unified identity and access control is the practical shape of CRA compliance. The article points to one control plane spanning human, machine, and AI actors, which is where lifecycle governance stops being an administrative process and becomes an enforcement layer. Teams should expect fragmented IAM, PAM, and secrets workflows to look increasingly out of step with regulatory proof requirements.
For practitioners
- Replace reusable credentials with short-lived identity Inventory SSH keys, API tokens, database passwords, and service secrets that still outlive a single task or session, then migrate the highest-risk paths to short-lived certificates or workload identities first.
- Enforce deny-first access for privileged paths Require explicit approval and resource scoping for all elevated access, and make denial the default for users, services, and processes that lack a current grant.
- Make access expiry automatic Set time-bounded access for administrative and operational tasks so the privilege disappears when the task ends, not when someone remembers to revoke it.
- Unify session logging across human and machine identities Collect authentication, session start and stop, configuration changes, and privilege grants into one structured audit stream that can be searched and exported for evidence.
- Extend governance to AI workloads Treat AI services and agents as governed identities with explicit ownership, constrained roles, and revocation paths instead of leaving them on implicit application trust.
Key takeaways
- The article frames CRA compliance as an architecture problem where identity, privilege, and auditability must be enforced by the system itself.
- Static credentials and standing privilege weaken both security and compliance because they make access hard to prove, constrain, and revoke.
- The practical response is to move toward short-lived identity, deny-first access, and tamper-resistant audit trails across human, machine, and AI workloads.
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 and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on replacing static credentials and leaked secrets with cryptographic identity. |
| NHI-05 — Overprivileged NHI | Deny-by-default access and JIT privilege directly address excessive non-human access scope. | |
| NHI-07 — Long-Lived Secrets | The article explicitly rejects long-lived tokens, passwords, and keys for infrastructure access. | |
| Recommendation — Eliminate reusable NHI secrets and move access to short-lived, identity-bound credentials. Scope NHI access to the minimum resource set and expire elevated rights automatically. Replace long-lived machine secrets with time-bound certificates and revocable workload identity. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's risk model is about stolen credentials becoming broad infrastructure reach. |
| Recommendation — Map secret exposure to credential access and lateral movement paths in your detection and response planning. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on enforcing access decisions through explicit grants and expiry. |
| Recommendation — Apply PR.AA-05 to make access permissioned, time-bounded, and auditable by design. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are central to the article's critique of static secrets. |
| AC-6 — Least Privilege | The article repeatedly ties CRA readiness to least privilege and zero standing privilege. | |
| Recommendation — Use IA-5 to govern issuance, rotation, revocation, and expiry of authenticators. Apply AC-6 to ensure elevated access is task-specific and removed when no longer needed. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is fundamentally about cloud identity controls across workloads and infrastructure. |
| Recommendation — Use IAM controls to unify identity, authorization, and lifecycle governance across cloud services. | ||
Key terms
- Cryptographic Identity: Cryptographic identity is a trust model in which authentication depends on verifiable keys, certificates, or signed assertions rather than shared secrets alone. It is essential for machines and agents because it gives the organisation a stronger way to prove identity and revoke access quickly.
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
- Deny By Default: Deny by default is an authorization rule that blocks access unless a policy explicitly permits it. It is the safer baseline for modern identity control because it limits accidental privilege expansion and makes every access grant visible, testable, and easier to review.
- Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Per-control mapping between CRA requirements and specific ENISA playbook principles
- Detailed examples of short-lived certificate issuance for SSH, Kubernetes, databases, and AI workloads
- Session recording and audit export mechanics for compliance evidence
- How access lists, SCIM, and lifecycle governance are structured across the stack
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org