Most large enterprises have some version of a vault program, the combination of policy, platform, process, and ownership used to manage machine credentials. It includes the secrets manager itself, the teams that operate it, the IAM policies that govern it, and the application teams expected to use it. The credentials themselves belong to machine identities: the service accounts, workloads, and AI agents actually doing the authenticating.

In an ideal world, every team would have the same stake and view into that program. Many do not. 

Teams can usually see which credentials made it into the vault. But every team, from security to IAM, cannot see the full population of machine credentials still living in repositories, pipelines, cloud environments, or collaboration tools. They also cannot easily tell which vaulted credentials have active copies sitting elsewhere.

That leaves IAM and Security teams responsible for a control they cannot fully measure. 

If a CISO or exec team member asks, "How much of our machine credential risk is under control?" many teams would struggle to answer. Unfortunately, they typically ask these questions after an incident, when the timing could not be worse.

All vaults, from AWS Secrets Manager to CyberArk Secrets Manager, can report metrics like uptime, secret count, request volume, and onboarding activity. Those figures show whether the platform is running. They do not show whether the organization is actually following the policy.

What you need is a full credential-layer security plan that includes vaults and wherever else secrets actually live.

Who owns vault coverage in your organization

Vault "ownership" is usually split across several groups. 

Security or IAM owns the policy and risk. Platform, infrastructure, or identity engineering runs the service. Application teams own the credentials used by their workloads. The CISO remains accountable for the broader credential risk reported to executive leadership and the board.

In reality, this means a fractured governance model in which IAM can publish the policy, platform teams keep the vault available, and application teams decide how quickly they adopt it.

The team members make those separate decisions, and in many orgs there is no central authority truly accountable for adoption. Their work continues when they bypass the vault. Builds pass and deployments complete, and then those plaintext credentials remain active. 

The plan for the control exists on paper. The actual compliance rate remains a big unknown. The gap becomes visible, unfortunately, most often during an audit, a manual review, or an incident.What all teams need, but especially the IAM and Security teams responsible for governance, is a shared, unified view of how many credentials exist across all surfaces. 

IAM needs to see policy coverage. Platform teams need to see adoption gaps. Application and Security teams see the credentials they need to manage and remediate. And ultimately, the CISO and board need to see whether risk is moving in the right direction.

Why secrets end up outside the vault

The simple answer of "why isn't everything already in a vault?" is friction. Developers hate toil, and vaults require setup, authentication, and integration work. Each platform comes with its own intricacies, meaning developers need to leave flow state to remember how to use the CLI to set the path correctly, then test and do all the needed process management steps. 

A credential placed in a local configuration file works immediately. An unmanaged CI variable also works immediately. The build passes, and the team moves on.

The credential may remain outside approved management for months or years.

The OWASP Top 10 for Non-Human Identities ranks downstream consequences, secret leakage, and long-lived, unmanaged credentials among its top items. GitGuardian's research gives the scale: 28.6 million new hardcoded secrets on public GitHub in 2025, and 64% of secrets confirmed valid in 2022 still valid years later (State of Secrets Sprawl 2026). Those numbers show the size of your credential sprawl that vault-native reporting alone cannot account for.

IAM and Security need visibility into the systems where those credentials are created, copied, and used.

How to measure vault program effectiveness

Any project needs measurable controls. IAM teams have long had a set of standard metrics that let them report on compliance and effectiveness. Access reviews have completion rates. Multi-factor authentication programs have enrollment rates. Privileged access programs track account onboarding and policy coverage.

Vault programs, though, often track only credentials that are already onboarded.

That produces a numerator. IAM still needs the denominator: the total number of known machine credentials across the organization.

Finding that number is difficult because credentials move through engineering systems without a central registration event. A credential may begin in a cloud platform. A copy may appear in a CI/CD variable. Another may end up in a Kubernetes manifest or application configuration.

How to calculate vault coverage

Vault coverage is the share of known machine credentials that reconcile to a managed vault.

Vault coverage = unique credentials matched to a managed vault ÷ unique credentials detected across connected sources

Getting these numbers requires discovery. This is where GitGuardian comes in. 

GitGuardian's credential-layer security platform detects credentials everywhere they should be and everywhere they shouldn't be. This means finding plaintext API keys in places like source control systems, CI/CD platforms, cloud environments, and collaboration tools. GitGuardian deduplicates each credential by value. The same credential appearing in several locations counts once in the coverage calculation. Each secret is then hashed, and a fingerprint is taken of each hash. 

GitGuardian then compares those detected credential fingerprints with the fingerprints of secrets in any connected vaults. The platform never stores the actual secrets, and your vaulted secrets always stay secure thanks to ggscout.

Why a vaulted secret can still be exposed

A service account credential may be stored correctly in Azure Key Vault or Delinea Secret Server, while the same active secret remains in multiple code repositories. That credential counts as matched for vault coverage, but the plaintext copy in the code still carries the risk.

When categorizing risks and prioritizing an action plan, GitGuardian helps IAM and Security teams broadly sort exposure risk into three cases:

- A credential that is vaulted and contained.
- A credential that is vaulted but still copied elsewhere.
- A credential that has never reached the vault.

Those cases require different actions, and security and IAM teams need to distinguish them quickly. The GitGuardian platform makes it straightforward to address that last, and highest risk, state. With our "push-to-vault" functionality, anyone working on an incident of a discovered plaintext secret can simply place it in the correct connected vault and set the path with ease. For secrets found in code, GitGuardian can even track the file with "Secret Presence" checks to show when the secret is properly removed from the same branch of the repo where GitGuardian first detected it.

The goal is to reduce risk, and vault coverage empowers you to prove you are.

Why vault coverage matters for compliance and the board

Vault coverage shows whether the secrets management investment is reaching the credentials it was purchased to protect. This answers one of the questions executive teams often ask. The other question boards and execs ask is if their investment has lowered risk. 

Part of that risk discussion is auditability and compliance. 

For example, PCI DSS 4.0 policy on hardcoded application and system account credentials started being enforced in March 2025. A discovery-based coverage metric can support an assessment. The list of unmatched credentials behind the metric can drive remediation. The stored-secret count alone cannot answer whether you have met those standards. A higher count may reflect adoption, continued credential growth, or migration from another platform.

Coverage adds the missing context. It can arm your whole enterprise for when auditors show up, before or after an incident, asking what steps you have taken to meet compliance standards. 

GitGuardian exposes machine credential risk in measurable terms, while giving you clear timelines and steps from the time you discovered a secret is out of compliance through how and when you remediated the incident.

How to report vault coverage to executives

Traditional vault reporting focuses on platform activity, but what exec teams care about, and what IAM and security need to understand, is total governance plan effectiveness.

How many known machine credentials are covered by the vault policy? Which teams account for the largest gaps? How many vaulted credentials still have unmanaged copies?

Which credentials have no clear owner?

GitGuardian gives the whole enterprise a standing view of those questions.

You can report coverage across the organization, track production coverage separately from lower-risk systems, and prioritize the teams with the largest gaps first.

Knowing the real coverage number gives IAM a starting point, a remediation backlog, and a way to show progress over time.

The conversations with execs and the board become more specific. Instead of answers like "Teams are still adopting vaults," we can empower reporting such as "Production vault coverage is 61%. The target is 80% by Q2. Three teams account for most of the unmatched credentials. A portion of matched credentials still appear in repositories."

That is a program that shows progress, has clear goals, and is understandable by leadership and stakeholders.

We would love to help you get on the road to better vault coverage as part of your credential security planning. Set up a demo today.

Common Questions About Vault Coverage