Topic starter
12/06/2026 9:46 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “SOC 2 Controls for Non-Human Identities: CC6, CC7, and CC8”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: SOC 2 control design for non-human identities fails when it assumes machine access can be governed through human-centric review patterns alone.
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
👉 Read Teleport's SOC 2 control mapping for non-human identities and machine evidence →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
13/06/2026 12:04 am
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.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: SOC 2 controls for non-human identities need machine evidence
This post was modified 4 days ago by NHI Mgmt Group