The Challenge
Your organization relies on machines communicating with each other. Service accounts authenticate to cloud platforms, API keys authorize CI/CD pipelines, and OAuth tokens connect microservices. These Non-Human Identities (NHIs) are essential to your automated workflows but don't appear in your employee directory.
A mid-sized financial services firm found they had over 8,000 active NHIs for 800 employees. The security team knew these credentials existed but lacked a systematic way to track their creation, rotation, or revocation. When SOC 2 auditors requested an inventory of all machine credentials with access to customer data, the team spent three weeks manually cataloging secrets across GitHub repositories, CI/CD configurations, and cloud IAM policies. They discovered 340 credentials they couldn't attribute to any current system or owner.
The compliance gap was evident: you can't demonstrate least-privilege access controls without knowing what identities exist or what they can access. PCI DSS v4.0.1 Requirement 7.2.2 mandates restricting access to cardholder data based on job classification and function. But how do you apply job classification to a service account?
The Environment and Constraints
The firm operated in a hybrid environment: legacy on-premises systems for core banking functions, AWS for customer-facing applications, and Azure for analytics workloads. Three development teams shipped code independently, each with their own approach to secrets management.
The R&D teams prioritized speed. Developers created service accounts and API keys as needed, often during incident response or deployment troubleshooting. These credentials rarely got documented in the team wiki, let alone a centralized registry. The security team learned about new NHIs only when they appeared in CloudTrail logs or triggered anomaly alerts.
The compliance team needed to demonstrate continuous control effectiveness for SOC 2 audits. They required evidence that machine credentials followed the same governance as human identities—provisioning approval, regular access reviews, and prompt deactivation when no longer needed. The existing ticketing system tracked employee onboarding and offboarding, but service accounts were outside that workflow.
Budget constraints meant they couldn't purchase a comprehensive NHI management platform. The CISO approved budget for point solutions, but any broader initiative needed to show ROI within two quarters.
The Approach Taken
The team focused on visibility first. They built an NHI inventory by aggregating data from multiple sources: cloud IAM APIs, secrets management tools (using HashiCorp Vault for application secrets), and a custom script that scanned CI/CD configurations for embedded credentials. This inventory became a living document, updated weekly through automated collection.
Each NHI was tagged with metadata: creating team, associated application, permission scope, and last rotation date. This tagging revealed patterns. The analytics team had 40 service accounts in Azure, but only 12 were actively used in the past 90 days. The payments team had API keys with broad S3 bucket access when they only needed read permissions for transaction logs.
They bridged the security-R&D gap by embedding a security engineer in sprint planning. Instead of blocking deployments that violated policy, the security engineer helped developers create NHIs correctly from the start. They built Terraform modules that provisioned service accounts with least-privilege permissions by default and automatically registered them in the inventory. Developers got faster provisioning; security got better hygiene.
For automation, they implemented a rotation policy tied to risk level. High-risk credentials (those with write access to production databases) rotated every 30 days. Medium-risk credentials rotated quarterly. The rotation process used the cloud provider's native credential management APIs—AWS Secrets Manager for RDS credentials, Azure Key Vault for service principal secrets. Applications pulled credentials from these vaults rather than environment variables, eliminating the need to redeploy when credentials rotated.
They addressed the compliance documentation gap by treating NHI lifecycle events as audit logs. Every provisioning request, permission change, and deactivation generated a structured log entry that mapped to specific control requirements. When auditors asked about Requirement 8.2 (unique ID assignment), they could produce a complete history for any service account.
Results and Metrics
The inventory revealed that 23% of active NHIs had permissions exceeding their functional requirements. The team systematically reduced these to least-privilege, directly addressing ISO 27001 Control 8.2 (privileged access rights). This reduction didn't break any applications, indicating that the original permissions were over-provisioned.
The 340 unattributed credentials were deactivated over six weeks. The team disabled them in staging first, monitored for broken integrations, then removed them from production. Zero incidents resulted from these deactivations.
Automated rotation reduced the average credential age from 287 days to 45 days for high-risk NHIs. The team measured this as "percentage of credentials rotated within policy window" and reported it monthly to the CISO.
The compliance team cut audit preparation time by 60%. Instead of scrambling to document NHI controls during the audit window, they maintained continuous evidence collection. The audit report noted "effective controls over non-human identity management" as a strength.
What They Would Do Differently
The team initially treated NHI management as a security project. In hindsight, they should have positioned it as an operational efficiency initiative from day one. Developers cared more about reducing the time spent troubleshooting credential-related deployment failures than compliance controls. Leading with "faster, more reliable deployments" would have accelerated R&D adoption.
They also underestimated the complexity of credential rotation for legacy systems. Modern cloud-native applications handled automated rotation gracefully, but older on-premises services expected static credentials. The team ended up maintaining a separate process for these systems, which added operational overhead. Starting with cloud-native workloads and treating legacy systems as a phase-two effort would have delivered value faster.
The metadata tagging scheme evolved three times as they learned what attributes mattered for access reviews and incident response. They wish they'd interviewed SOC analysts and compliance managers before designing the schema. Questions like "What information do you need to make a keep/revoke decision during an access review?" would have saved rework.
Takeaways for Your Team
Start with an honest inventory. You can't manage what you can't see. Use cloud provider APIs, secrets scanning tools, and configuration audits to find NHIs wherever they live. Accept that your first inventory will be incomplete—you'll discover more credentials as you operationalize the process.
Treat NHIs as first-class identities in your IAM program. They should follow the same lifecycle as human accounts: formal provisioning, regular access reviews, prompt deactivation. If your employee offboarding checklist doesn't include "review service accounts created by this person," add it.
Embed security in development workflows rather than enforcing it through policy. Terraform modules, CLI tools, and API wrappers that make secure provisioning easier than insecure shortcuts will change behavior faster than any policy document.
Automate credential rotation for any NHI with access to sensitive data. The NIST Cybersecurity Framework emphasizes continuous monitoring and response. Static credentials are the opposite of continuous—they're set-and-forget until they're compromised. Modern secrets management tools handle rotation; your job is to integrate them into application architecture.
Measure what matters for your stakeholders. Security teams care about risk reduction. Compliance teams need audit evidence. R&D teams want to ship faster. Your NHI management program should produce metrics that speak to all three audiences.
Non-Human Identities are infrastructure, not an afterthought. Organizations that treat them as such enjoy reduced risk, improved compliance posture, and increased operational efficiency. Those that don't are running blind with thousands of unmanaged credentials that represent unquantified risk.
