TL;DR: Teleport’s analysis finds that SOC 2 control mappings for non-human identities now need machine evidence, including attestation, short-lived credentials, audit logs, and declarative change records across CC6, CC7, and CC8. The governance gap is no longer whether machines have access, but whether that access is provably authorised, reviewable, and revocable at machine speed.
At a glance
What this is: This is a SOC 2 control-mapping analysis showing how non-human identities can be governed with attestation, audit logs, short-lived credentials, and declarative change evidence.
Why it matters: It matters because IAM, IGA, PAM, and compliance teams need machine-access evidence that auditors can verify, not just human-centric access controls.
👉 Read Teleport's SOC 2 control mapping for non-human identities and machine evidence
Context
SOC 2 programmes still tend to treat logical access as a human-user problem, but modern infrastructure depends on non-human identities that request credentials, reach databases, and move data. Once bots, workloads, and AI agents become part of production access paths, the question shifts from who approved the user to what evidence proves the machine was authorised.
The gap is not theoretical. If a control mapping can describe human access but not machine attestation, credential issuance, review, and change history, auditors are left with partial evidence and teams are left with a control that does not match how the environment actually operates. That is why machine evidence has become a governance requirement, not just an implementation detail.
Key questions
Q: What breaks when SOC 2 controls are written for humans only?
A: Human-only mappings leave machines without a proof path for authorisation, review, and revocation. The result is a control narrative that may describe policy but cannot evidence workload identity decisions, credential issuance, or configuration change history. That gap becomes visible during audit because the machine activity is real even when the control model is not.
Q: When should teams prioritise machine evidence over access policy language?
A: As soon as non-human identities can reach production systems, evidence should be treated as part of the control, not an afterthought. If the environment depends on bots, workloads, or AI agents, the audit question becomes whether issuance, TTL, and revocation can be proven at the moment access is granted.
Q: What do security teams get wrong about machine identity management?
A: Security teams often treat certificates, keys, and tokens as infrastructure details instead of governed identities. That mistake leaves gaps in ownership, offboarding, and rotation. Once machine credentials are viewed as identities, the programme can apply the same lifecycle discipline used for access control and privileged accounts.
Q: What happens when machine identity changes are not managed as code?
A: Change history becomes hard to reconstruct, which weakens both operational control and audit evidence. Declarative machine identity rules preserve who changed what, when they changed it, and which approvals or pipelines applied the update.
Technical breakdown
Workload attestation turns machine identity into an evidence source
Workload attestation verifies attributes of the requesting process before a credential is issued. In this model, the system checks properties such as namespace, service account, or Linux user, then compares them against access rules that define which workloads may receive credentials. That replaces static secrets with policy-driven, short-lived access and creates a record of why issuance succeeded or failed. For SOC 2, the technical point is not merely authentication. It is proving that the credential was bound to an authorised workload at request time, which gives auditors something machine-specific to inspect.
Practical implication: build evidence collection around credential issuance decisions, not just the existence of a machine account.
Short-lived certificates narrow the abuse window for machine credentials
Machine credentials behave differently when they expire quickly. Short-lived certificates reduce the time in which a stolen credential remains useful, while TLS protects transmission and memory-only use can avoid writing secrets to disk. The control value is not that certificates exist, but that their time-bound nature constrains blast radius and aligns access with the task duration. For SOC 2 CC6.6, that turns credential protection into a lifecycle question: how quickly the credential can expire, renew, or be revoked after issuance.
Practical implication: prefer time-bounded machine credentials and require evidence of TTL, renewal, and revocation handling.
Declarative configuration creates change evidence for machine access
Machine identity controls become auditable when registrations, join methods, access rules, and signature checks are managed as declarative resources. Version control, pull requests, and automated pipelines provide a traceable record of proposed, approved, and applied changes. That matters because SOC 2 CC8.1 is not just asking whether change occurred. It is asking whether machine-access changes were controlled in a way that can be reconstructed later. Audit logs then fill the gap between what was approved and what was actually applied.
Practical implication: manage machine identity rules as code so every change has review history, timestamps, and an audit trail.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
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
Machine evidence is now the missing control plane for SOC 2 identity governance. Human-centric access reviews do not answer the audit question when the subject is a workload, bot, or AI agent. SOC 2 evidence has to show authorisation at issuance time, ongoing access scope, and controlled change history for non-human identities. The practical conclusion is that machine access must be governed as a first-class identity domain, not as an exception to human IAM.
CC6, CC7, and CC8 only become usable when the machine itself leaves evidence. A policy that cannot prove who or what requested a credential, why it was allowed, and whether the configuration changed cleanly will struggle under audit. Workload attestation, denied issuance logs, and versioned configuration are not add-ons here. They are the minimum artefacts that let the control operate across machines at production speed. Practitioners should treat evidence generation as part of the control design.
Standing privilege and static secrets are the wrong baseline for machine identities. The article’s core implication is that machine access should be evaluated by issuance logic, TTL, and revocation traceability rather than by long-lived membership models. That is especially important where CI/CD pipelines, microservices, and automated bots outlive the original deployment assumption. The conclusion is simple: SOC 2 control mappings for NHIs fail when they assume machine access behaves like human access.
Declarative machine identity configuration is a governance requirement, not a convenience. When bot registrations, join methods, and access rules are expressed as code, they can be reviewed, versioned, and exported for audit. That creates the proof path for CC8.1 while also reducing configuration drift across machine populations. The practitioner takeaway is to align machine identity change control with the same discipline already expected for production infrastructure.
Auditors will increasingly look for machine-specific artefacts, not just control descriptions. A SOC 2 narrative that says access is restricted is weaker than one that shows attestation logs, revocation timestamps, and rule-change history. That shifts the compliance burden from policy language to operational proof. Teams that cannot surface those artefacts will find that non-human identities create evidence gaps even when their controls exist on paper.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs
What this signals
Machine evidence is becoming the control boundary for non-human identity governance. Access review cadences built for people do not map cleanly to workloads that request credentials, use them briefly, and disappear. Practitioners should shift the centre of gravity from periodic review to issuance-time proof, because that is where machine identity risk is actually decided.
Short-lived credentialing changes the meaning of compliance evidence. If a certificate is only useful for a narrow window, the evidence problem is not whether access existed in theory but whether the system can show who authorised it, for how long, and under what rule. That is a stronger fit for SOC 2 than static secret inventories alone.
Machine-access governance now needs a named operating concept: evidence at issuance. That means the access decision, the workload attributes, and the resulting credential must be captured together. For teams running NHIs, that is the point where compliance, security, and auditability finally line up.
For practitioners
- Audit machine-access evidence gaps Map every non-human identity path to the evidence an auditor would need: attestation result, issuance decision, credential TTL, revocation record, and configuration change history.
- Replace static secrets with short-lived credentials Set machine credentials to expire quickly, renew automatically where needed, and keep the issuance record tied to the workload attributes that justified access.
- Version machine identity rules as code Store bot registrations, join methods, access rules, and signature checks in version control so approvals and applied changes can be reconstructed later.
- Export denied issuance and revocation logs Make failed credential requests, lock actions, and revocations available for review so access decisions can be correlated with control outcomes.
- Review standing privilege across workloads Use access graphs or equivalent exports to find bots and services that still hold permissions no longer justified by their current purpose.
Key takeaways
- SOC 2 control design for non-human identities fails when it assumes machine access can be governed through human-centric review patterns alone.
- The article’s core evidence model combines attestation, short-lived credentials, and configuration history so auditors can reconstruct access decisions.
- Teams should treat issuance logs, revocation records, and declarative change control as required proof for machine identity governance.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and SOC 2 (AICPA) defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on how workloads prove identity before credentials are issued. |
| NHI-05 — Overprivileged NHI | It highlights review of workload roles and standing privileges across bots and services. | |
| NHI-07 — Long-Lived Secrets | Short-lived certificates are presented as the alternative to static, durable machine credentials. | |
| Recommendation — Use attestation and bound proof methods to ensure machine identities authenticate before receiving access. Review workload entitlements regularly and remove access that no longer matches the current role. Replace long-lived machine secrets with time-bounded credentials and document renewal and revocation. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Authentication | The control mappings depend on authenticating services and workloads, not just people. |
| IA-5 — Authenticator Management | Credential lifecycle, renewal, and revocation are central to the article’s SOC 2 mapping. | |
| AC-6 — Least Privilege | Periodic review of bot roles and standing privileges is a direct theme in the article. | |
| Recommendation — Apply service authentication controls to require proof of workload identity before issuing credentials. Manage machine authenticators with short lifetimes, renewal rules, and immediate revocation records. Limit workload permissions to the minimum needed and remove excess access after review. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article focuses on registering, reviewing, and revoking machine identities as accounts. |
| Recommendation — Track machine accounts through their full lifecycle and revoke those that are no longer authorised. | ||
| SOC 2 (AICPA) | CC6.1 — Restrict logical access | This is the article’s core SOC 2 access-control mapping for non-human identities. |
| CC6.2 — Register and authorise entities | The article emphasises bot registration before credential issuance and revocation after deprovisioning. | |
| CC6.3 — Review access roles and rules | Periodic review of workload roles and rules is explicitly discussed as an audit need. | |
| Recommendation — Demonstrate that only authorised workloads receive access and retain the issuance evidence. Register machine identities before issuance and keep timestamped proof of authorisation and revocation. Export and review machine access rules to identify privilege creep and stale assignments. | ||
Key terms
- Workload Attestation: Workload attestation is the process of proving that a workload is running in an expected, trusted environment before granting access. It helps stop copied credentials from being treated as universally valid and is a core control for reducing impersonation risk.
- Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
- Declarative Machine Identity Configuration: Declarative machine identity configuration is a code-based way to define registrations, join methods, access rules, and verification policies. It creates a versioned record of who changed what and when, which is essential when auditors need to reconstruct access governance for workloads and bots.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Control-by-control mapping across CC6.1, CC6.2, CC6.3, CC6.6, CC7.2, CC7.3, and CC8.1
- What evidence auditors can use for denied credential issuances, revocation events, and configuration changes
- How workload attestation, Sigstore checks, and bound keypairs support machine-specific access proof
- How Teleport exports access rules and audit logs for SOC 2 evidence collection
👉 Teleport's full article covers the CC6, CC7, and CC8 evidence trail in more operational detail.
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 June 12, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org