NHI Inventory & Discovery Best Practices: The Hidden Tokens Lurking in Your Code
- The Visibility Gap: Most enterprises underestimate their machine identity count by a factor of 5x to 10x.
- Hardcoded Risks: Developers frequently embed long-lived secrets in code, creating "shadow" access points.
- Orphaned Identities: Service accounts often outlive the workloads they were created for, leaving open doors for attackers.
- Automated Scanning: Manual spreadsheets are obsolete; continuous scanning of repositories and cloud IAM is mandatory.
- Immediate Action: You must treat discovery as a continuous process, not a one-time audit.
The Silent Leak in Your Cloud
You cannot secure what you do not know exists.
For most organizations, the "known" inventory of machine identities is just the tip of the iceberg. The real danger lies below the surface: shadow bots, forgotten API keys, and hardcoded secrets.
To stop the leak, you need rigorous nhi inventory and discovery best practices.
This deep dive is part of our extensive guide on Non-Human Identity (NHI) Security & Governance: Why Machines Are Your Biggest Attack Surface.
If you rely on manual spreadsheets to track service accounts, you are already compromised. Modern DevOps environments spin up thousands of ephemeral workloads daily. A static list cannot keep pace with this velocity.
This guide focuses purely on the discovery phase—identifying the hidden tokens and shadow identities lurking in your infrastructure.
Phase 1: Hunting Hardcoded Secrets
The most common location for leaked machine identities is your own source code.
Developers often prioritize speed over security, hardcoding API keys or connection strings directly into scripts to make them work "temporarily."
Where to Scan:
- Public & Private Repositories: GitHub, GitLab, Bitbucket.
- Container Images: Docker files often contain baked-in credentials.
- Configuration Files: YAML, JSON, and XML files in S3 buckets.
The Danger of "Commits": Even if a developer deletes a key from the current version of the code, it often remains in the commit history. Discovery tools must dig through historical logs, not just the main branch.
Once you identify these exposed secrets, the next step is remediation. For a guide on fixing these issues, refer to our tutorial on Securing Service Accounts and Bots: A DevOps Tutorial to Kill Long-Lived Secrets.
Phase 2: Detecting "Shadow" Machine Identities
Shadow Machine Identities are accounts created outside of standard governance processes. These often occur when a DevOps engineer creates a "test" service account in a cloud console and forgets to delete it.
How to find them:
- Compare IAM vs. CMDB: Cross-reference your Cloud IAM list (AWS/Azure/GCP) against your central Configuration Management Database. The delta is your "Shadow" list.
- Analyze API Logs: Look for traffic coming from identities that do not map to known applications.
- CIEM Tools: deploy Cloud Infrastructure Entitlement Management (CIEM) to visualize excessive permissions and unknown actors.
For a broader architectural view of how to structure this, see our Machine Identity Security Framework.
Phase 3: The Threat of Orphaned API Keys
An orphaned API key belongs to a service or employee that no longer exists. When a developer leaves the company, HR disables their human account. But the bot accounts they created? They often stay active.
The Discovery Checklist:
- Last Used Date: Query your cloud provider for keys that haven’t been used in 90+ days.
- Owner Status: Map every key to a human owner. If the human is "inactive," the key is an orphan.
- Workload Correlation: Verify if the compute instance associated with the key is still running.
Why this matters: Hackers love orphaned keys. They are valid credentials that no one is monitoring.
Phase 4: Discovery Automation Tools
Manual audits fail because they provide a snapshot in time. By tomorrow, your inventory will be outdated.
Effective Discovery Tooling Requirements:
- Continuous Monitoring: Real-time scanning, not quarterly checks.
- Multi-Cloud Visibility: Ability to see AWS, Azure, and on-premise keys in one dashboard.
- Secret Detection: Regex-based scanning to identify patterns like
AKIA...(AWS keys) orghp_...(GitHub tokens).
Implementing these tools is a prerequisite for passing audits. If you are preparing for a regulatory review, verify your discovery completeness using our NHI Compliance Auditing Guide for 2026.
Frequently Asked Questions (FAQ)
You must use automated scanning tools (CSPM or CIEM) to query the IAM APIs of your cloud providers (AWS, Azure, GCP). These tools list all users, roles, and service accounts. You must then correlate this list with your active applications to identify discrepancies.
Orphaned keys are active credentials linked to deleted applications or departed employees. They are dangerous because they provide valid access but are not monitored, making them perfect vehicles for stealthy attacks by hackers.
Shadow identities are best detected by analyzing CloudTrail or activity logs. Look for identities performing actions that have no corresponding record in your provisioning system or governance platform.
Key tools include Secret Scanners (like TruffleHog or GitGuardian) for code, and CIEM platforms (like Wiz, CyberArk, or Prisma Cloud) for infrastructure visibility. These automate the detection of hidden accounts.
Discovery should be continuous/real-time. However, a formal audit and cleanup of your service account inventory should happen at least monthly to ensure your nhi inventory and discovery best practices remain effective.
Conclusion
The "Identity of Things" is expanding faster than human identity ever did.
Implementing robust nhi inventory and discovery best practices is the only way to close the visibility gap.
You cannot protect the attack surface you cannot see. Start scanning your repositories and IAM roles today. Identifying the leak is the first step toward stopping it.