Good Non-Human Identity Governance Means Maturing Your Enterprise Secrets Management

Learn why enterprise secrets management is a key component to building a robust non-human identity governance model and is required for securing the whole organization.

When you think of identity and access management (IAM), you traditionally think of humans. We’ve been managing human access management for decades and are getting progressively better at it. The cycle of onboarding a new employee or user, giving them access to the systems they need, and eventually safely offboarding them has a well-established set of best practices. The IAM tooling vendors re-enforce these governance policies for a good reason: they work.

Today, the enterprise is in a new era. Non-human identities (NHIs) outnumber human identities by a ratio of at least 50 to one. Some estimates put it as high as 100 to one in 2025. It is easy to find consensus that we should do something about NHIs, as the consequences of more and more breaches and leaks stemming from poor machine identity management, particularly credential management, mean we need to find a better path. The question a lot of leaders are asking themselves now is, “What does a good Non-Human Identity governance model look like, and how do we navigate our organizations there?”

The overlapping path of secrets management

There is one element of NHI management that has been studied for a while now, credential management. As all NHIs need a way to authenticate and the governance for storing and using those secrets is definitely part of the larger NHI story. Research into how companies evolve their secrets security practices produced the Secrets Management Maturity Model.

The model describes organizations transitioning from Level 0, where no secrets security is in place, to Level 3, where enterprise vault technology becomes the standard, and secrets detection is automated at every level of the SDLC, including on the developer’s machine. The most mature organizations at Level 4 are working to remove credentials as much as possible, moving to alternative authentication and authorization strategies for their services and data.

Secrets Management Maturity Level 0

Companies at the beginning of their journey don’t consistently implement controls around secrets. If they do, they were simple ENV files passed around in plain text. All too often, plaintext credentials are hardcoded into the code itself.

Secrets Management Maturity Level 1-2

As companies mature, secrets management becomes more of a recognized problem. We see the wider adoption of secret management tools, especially those built into cloud platforms like AWS, Azure, or Google Cloud. As long as a company standardizes on the same cloud provider for everything, these work well for putting your secrets somewhere safe, encrypted at rest, and programmatically addressable when needed. The adoption of secret discovery tools to continually find hardcoded credentials in code or surrounding systems has become commonplace, and developer tools to prevent secrets from being leaked in the first place have been introduced. All rotation and remediation efforts are still manual and reactive.

Secrets Management Maturity Level 2-3

Cross-platform centralized vault systems to properly store and manage secrets, such as HashiCorp Vault, Conjure by CyberArk, and Akeyless, get adopted at this stage. Automation becomes one of the main goals, particularly around credential rotation. The developers are involved early and throughout the remediation process as well.

Secrets Management Maturity Level 4

The most mature organizations actually seek to remove credentials as much as possible. Teams move to alternative authentication and authorization strategies for their services and data. These companies establish policies for rapid, possibly automated, remediation, which can only be possible with a sophisticated toolchain leveraged by coordinated teams across the entire organization.

Non-Human Identity Governance Maturity

While secrets management maturity gives us a solid base model and addresses one of the more serious security control concerns, it is not the whole story of NHI governance. We will need to think broader than just the storage and retrieval of the secrets and think about the entire life cycle, ownership, and risk management of our NHIs. But we need to start somewhere

The first step in any threat modeling or organizing exercise is the deceptively simple act of understanding what you have. Did you keep track of when they were introduced? Is there a dashboard or spreadsheet listing them all? While there are a lot of ways you can approach this, one method means properly mapping what secrets exist and understanding how they are used.

Once all of your secrets are discovered, then it’s time to enforce a centralized observable system to keep track of them, ideally in an enterprise secrets vault. A good secrets management platform can track when an NHI’s credential is created and when it’s rotated. They can report on what permissions the NHI holds. They can show when a credential was used and what it connects to. Ultimately, they can help you audit when a key is decommissioned.

It is critical to have this data before we think about broader policies for governance at scale.

Ownership is key

Once your NHIs are mapped and understood, we must address the daunting question of risk ownership. Who should own NHIs in the organization is a subject of much debate. Is it the developer who initially introduces the machine identity into the ecosystem? Is it the DevOps or Platform team who will need to utilize the secret for builds and deployments? Is it the security team, who is on the hook for breaches and incident response?

Today there is no clear consensus in the tech community on who actually should own this. Every company navigates this independently and comes to its own conclusions. No matter who gets ownership responsibility, they will only be successful if they are armed with the right data and insights into their systems.

Evolving IAM To Account For NHIs

The largest and most mature organizations have begun to account for NHIs as part of the overall IAM landscape. This trend will continue for the rest of the industry and at an accelerated pace. The NHI tooling market, which is rapidly emerging, is reacting to more and more leaders looking for a clear and sane way ahead.

Understanding the global lifecycle management of all your NHIs at scale is something that’s going to take a lot of work and alignment across organizations. This goes beyond anything that Security, IT, or DevOps can handle alone or without buy-in from the whole organization.

Author Bio

GitGuardian Security Advocate – Dwayne has been working as a Developer Relations professional since 2016 and has been involved in the wider tech community since 2005. He loves sharing his knowledge.