CRA secure-by-design demands new identity controls for AI workloads

At a glance

What this is: Teleport argues that CRA-aligned infrastructure must replace static credentials with cryptographic identity, default-deny access, and auditable lifecycle controls.

Why it matters: That matters because IAM, NHI, and PAM teams now have to prove identity controls in architecture and audit evidence, not just policy language.

By the numbers:

• The EU Cyber Resilience Act (CRA) enters its enforcement window in 2027, but preparations should start now.
• There are 22 actionable security playbooks in ENISA's Secure by Design and Default Playbook v0.4.

👉 Read Teleport’s mapping of CRA secure-by-design principles to identity controls

Context

The core issue is not whether organisations have identity controls, but whether those controls are built into the product and infrastructure layer from the start. For CRA-aligned environments, the primary keyword is identity governance, because compliance now depends on proving how humans, machines, and AI workloads are authenticated, authorised, logged, and retired.

Teleport’s article frames the CRA as a mandate for secure defaults, cryptographic identity, and audit-ready access decisions rather than a checklist exercise. That is a familiar direction for NHI governance, but the article extends it into product security expectations that will affect infrastructure teams, platform owners, and any group operating connected systems in the EU.

Key questions

Q: How should security teams replace static credentials in CRA-aligned environments?

A: Replace reusable secrets with short-lived certificates or workload identities wherever the platform allows it. Prioritise admin paths, production access, and automation accounts first, because those are the highest-value abuse points. The goal is not just rotation, but eliminating standing secrets that can be copied, reused, or shared outside the intended session.

Q: Why does zero standing privilege matter for CRA readiness?

A: Because the CRA expects access decisions to be controlled, bounded, and demonstrable. Persistent elevation makes it harder to prove that access was necessary at the moment it was used, and it expands the damage window if an identity is misused. JIT access reduces both operational risk and audit ambiguity.

Q: What breaks when AI workloads share one broad service identity?

A: A shared service identity creates standing privilege across training, inference, logging, and preprocessing. That broad scope makes it easier for a mistake or compromise to expose more data than any single function needs. It also weakens accountability because access logs no longer show which stage actually required the permission. Separate identities by function and remove unused cross-stage access.

Q: Who is accountable for lifecycle offboarding when machine access outlives the project?

A: The owning team remains accountable until the credential, role, or workload identity is revoked and the audit trail shows that revocation happened. Lifecycle ownership should be explicit in the access record, especially for partner integrations, service accounts, and AI workloads that may persist beyond the original deployment team.

Technical breakdown

Cryptographic identity and static credential removal

The article’s central technical argument is that static secrets are incompatible with secure-by-design infrastructure. Short-lived X.509 certificates and SPIFFE-compatible workload identities replace SSH keys, passwords, and long-lived API tokens, which reduces leakability and makes access traceable to a specific identity and task. This is an NHI pattern, not a cosmetic authentication change, because the credential itself becomes ephemeral and bound to policy. In practice, the control objective is to stop reusable credentials from becoming the universal bypass path across human, service, and AI-driven access paths.

Practical implication: map every long-lived credential in scope to a short-lived identity alternative and document where the replacement is not yet possible.

Deny-by-default RBAC and zero standing privilege

Teleport describes access as explicitly granted, time-bound, and dual-authorised, which is the operational shape of zero standing privilege. Deny rules take precedence over allows, roles are scoped by labels, and the certificate subject carries the role context so authorisation is cryptographically anchored to the session. That architecture matters because it prevents policy drift between grant and use. For IAM and PAM teams, the key point is that standing access is no longer just a governance smell. Under CRA-style expectations, it becomes an architectural liability that should not exist outside tightly bounded exceptions.

Practical implication: redesign privileged access so approvals, role scope, and session expiry are enforced together rather than managed as separate processes.

Unified audit trails for infrastructure and AI workloads

The article ties CRA logging expectations to a structured audit layer that records authentication, access requests, session activity, and administrative changes. It also extends that logging to AI workloads and agentic identity through SPIFFE-issued credentials and bot roles, which matters because agent-to-tool activity can only be governed if the access path is observable. The technical value is not just logging volume, but the fact that the audit source is the identity control plane rather than scattered host logs. That gives compliance teams a consistent evidence chain across SSH, Kubernetes, databases, applications, and AI agents.

Practical implication: centralise identity event capture so audit evidence is generated by the access layer, not reconstructed after the fact.

NHI Mgmt Group analysis

Cryptographic identity is becoming the compliance baseline for non-human access. The article makes clear that the CRA’s secure-by-design expectations are not satisfied by policy statements alone. Static credentials, shared secrets, and vague machine ownership now create evidence gaps as well as attack surface. For IAM and NHI programmes, the practical conclusion is that identity format is part of compliance posture, not just security hygiene.

Zero standing privilege is no longer only a PAM design choice. Once access must be provable, time-bounded, and task-scoped, standing privilege becomes difficult to defend in both operational and regulatory terms. That shifts JIT access from a convenience feature to a control expectation for privileged infrastructure and workload access. Practitioners should treat persistent elevation as an exception requiring explicit justification.

Agentic identity extends CRA-style governance into a new control domain. The article’s treatment of AI workloads shows why workload identity standards such as SPIFFE matter beyond traditional service accounts. AI agents that can initiate tool use, request access, and act across systems need the same governance chain as any other machine identity, but with tighter traceability. The implication is that agent access cannot sit outside identity architecture and still be considered controlled.

Securing the stack now means aligning product design, access policy, and audit evidence. The article’s strongest contribution is the linkage between secure-by-design requirements and the identity plane that proves them. That puts IAM, PAM, NHI governance, and platform engineering into a single operating model. Teams that still separate those functions will struggle to show how their controls work end to end.

Access governance and lifecycle management is the overlooked CRA pressure point. ENISA’s lifecycle guidance and the article’s SCIM-based offboarding emphasis show that secure design fails if access survives organisational change. That is especially relevant for service accounts, partner access, and AI workloads that outlive the teams that created them. Practitioners should view lifecycle offboarding as part of product security evidence, not an administrative afterthought.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to NHI Mgmt Group research.
• For lifecycle and offboarding depth, see Ultimate Guide to NHIs and Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Cryptographic identity will become the easiest CRA control to evidence and the hardest to fake. As product teams align with secure-by-design expectations, identity proofs will matter more than written policy because they are directly testable in architecture and logs. That means platform and IAM teams should expect greater scrutiny of short-lived credentials, device trust, and the audit lineage behind every privileged action.

Secure-by-default is pushing NHI governance into product engineering. The article’s real message is that lifecycle, privilege, and logging controls can no longer live only in GRC tooling or periodic review processes. They have to be built into the access layer so that connected products can prove who or what accessed them, when, and under which policy.

NHI sprawl becomes more visible once organisations treat AI workloads as identities, not tasks. With 92% of organisations exposing NHIs to third parties, according to Ultimate Guide to NHIs, the next governance step is to distinguish managed workload identity from unmanaged automation. That is where the identity control plane concept becomes useful: the access layer becomes the system of record for human, machine, and agent activity.

For practitioners

• Inventory every static credential in scope Build a full register of SSH keys, database passwords, API tokens, and other reusable secrets across human, service, and AI access paths. Mark which systems still depend on long-lived secrets and which can move to short-lived certificates or workload identity.
• Make privileged access time-bound by default Require just-in-time approvals for elevated access, with automatic expiry and dual-authorisation for high-risk resources. Keep the approval, use, and expiry events in the same audit trail so compliance evidence is complete.
• Tie device trust to connection policy Enforce registered-device checks before any privileged session is allowed, especially for admin consoles, databases, and production shells. Use hardware-backed attestation where available and block fallback access that bypasses device verification.
• Extend identity governance to AI workloads Assign explicit bot roles, workload identities, and session-level logging to AI agents and automation processes that touch infrastructure. Do not let agent-driven access sit outside the same review, approval, and revocation process used for other non-human identities.

Key takeaways

• The CRA turns identity design into a compliance requirement, not an implementation preference.
• Static secrets, standing privilege, and weak lifecycle offboarding are the main gaps exposed by this model.
• Teams should treat audit evidence, workload identity, and JIT access as core product-security controls, not add-ons.

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.
• Device Trust: Device trust is the confidence that a requesting endpoint is known, managed, and in a compliant state. It matters because identity alone does not prove safety. In zero trust programmes, device trust becomes one of the inputs used to decide whether access should be granted or sustained.
• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.

What's in the full article

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

• How Teleport maps each CRA and ENISA principle to specific infrastructure controls and product behaviours.
• The full breakdown of its audit trail, session recording, and access request workflow across SSH, Kubernetes, databases, and AI agents.
• The article's detailed treatment of SPIFFE credentials, device trust, and lifecycle management across the full stack.
• The architectural argument tying secure-by-design requirements to identity, policy, and evidence generation.

👉 Teleport’s full article details the control-by-control CRA alignment across identity, audit, device trust, and AI workloads.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity security programme, it is worth exploring.