Identity Infrastructure: Why Credentials Matter More Than Directories

The part of identity infrastructure your directory was never built to see

In 2025, GitGuardian detected millions of new hardcoded secrets across customer environments. These are working credentials to real systems: API keys, service account tokens, database connection strings, OAuth secrets, and cloud keys. Each one can authenticate an identity, service account, workload, or integration somewhere in the environment. Once exposed, those credentials can be copied, reused, and rediscovered far from the system that issued them.

This is where modern identity infrastructure extends beyond the directory: into the credentials moving through code, pipelines, collaboration tools, and developer environments. Securing that layer requires visibility into where credentials are exposed or mismanaged, without disrupting the systems that already manage identity lifecycle and access policy.

What is identity infrastructure? A complete picture

Modern digital identity infrastructure spans three layers: governance, credentials, and enforcement.

The governance plane: directories, identity providers, and lifecycle management. This is the identity services infrastructure where most identity and access management (IAM) infrastructure investment concentrates:

• Identity directories: Active Directory, Entra ID, LDAP, etc. The authoritative record for users, groups, and sometimes service accounts.
• Identity providers: Okta, Entra ID, Ping Identity, Auth0, etc., handling authentication, authorization flows, and token issuance.
• Identity Governance and Administration (IGA): SailPoint, Saviynt, ConductorOne, etc. Access certification, provisioning, and compliance reporting.
• Privileged Access Management (PAM): CyberArk, BeyondTrust, Delinea, etc. Governs and vaults privileged credentials.
• Identity orchestration: Strata Identity, Ping DaVinci, Simeio, etc. Unifies fragmented identity systems into coordinated workflows.

These categories include many of the core tools enterprises use to manage IAM infrastructure at scale, and a typical organization runs several of them side by side.

The credential plane: tokens, keys, secrets, and certificates. This is where identity management infrastructure meets the artifacts that actually grant access:

• API keys and tokens: bearer tokens, OAuth access and refresh tokens, JSON Web Tokens, and personal access tokens.
• Service account credentials: Kubernetes ServiceAccount tokens, cloud IAM service account keys, and machine-to-machine client secrets.
• Certificates: TLS and mutual TLS certificates for service-to-service authentication, and client certificates for API access.
• Secrets and connection strings: database credentials, SaaS integration secrets, SMTP passwords, and cloud storage access keys.
• SSH keys: developer and automation keys for repositories, servers, and pipelines.
• Secrets managers and vaults: HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Akeyless, Delinea, and similar systems that store, rotate, broker, and audit access to credentials.

Some credentials are issued by governance-plane systems. Others come from cloud services, SaaS platforms, developer tools, package registries, or one-off integrations. Once issued, they move through code, configuration files, CI/CD pipelines, collaboration tools, and developer workstations, far from the systems that created or governed the identity in the first place.

The enforcement layer: where identity meets cloud, network, and workloads. This is where identity decisions are applied at runtime:

• Cloud IAM: AWS IAM, GCP IAM, and Azure role-based access control enforcing permissions across cloud resources.
• Kubernetes identity: Kubernetes RBAC, ServiceAccounts, and workload identity federation governing access between workloads and clusters.
• Service mesh and workload identity: Istio, Linkerd, Cilium, and mutual TLS carrying trust between services.
• API gateways: token validation, authorization checks, and policy enforcement at the perimeter.

In hybrid identity infrastructures, enforcement spans on-premises directories, multiple cloud IAM systems, Kubernetes clusters, and SaaS platforms. That spread multiplies credential handling, and the exposure that comes with it.

Identity infrastructure blind spots: where the estate extends beyond the directory

The most common identity infrastructure blind spots are non-human identities without clear ownership, credentials that persist after deprovisioning, machine credentials that function as identities, fragmented credential handling across hybrid and multi-cloud environments, and compliance evidence that directories cannot produce.

Directories were built for people, not non-human identities at this scale

Most directories were designed around human users. Non-human identities, including service accounts, API keys, OAuth apps, and CI/CD credentials, often sit partly or wholly outside directory governance. Service accounts created directly in cloud IAM or Kubernetes may never appear in the corporate directory. API keys issued by SaaS platforms are managed per service, not centrally. Developer-created tokens proliferate in git repositories, .env files, and CI/CD configs, where directories do not reach.

With machine identities outnumbering humans 109 to 1, the practical problem becomes ownership. The first question about any service account is “whose is it?”, and the directory has no answer for an account it never held. A workable non-human identity security strategy starts by answering that question from the signals that do exist in the engineering layer: commit history, deployment configuration, and usage patterns.

Credentials outlive their directory entries

When an employee leaves or a service is decommissioned, the directory entry is deactivated. The credentials that identity used can persist. API keys embedded in application code keep working until they are revoked at the issuing service. Service account tokens committed to a repository remain in git history indefinitely, even after the account is deleted. OAuth refresh tokens cached in SaaS integrations can keep granting access after the authorizing identity is gone.

Deprovisioning removes the identity. It does not guarantee removal of every credential that identity ever held. That gap between identity lifecycle and credential lifecycle is a primary source of stale, exploitable access, and it is exactly the question a deprovisioning workflow cannot answer on its own: did we actually kill every key this account ever used? The persistence is measurable. 

Credentials spread faster than identity systems can track them

A credential rarely lives in only one place. The same API key may appear in a repository, a CI/CD variable, a build log, a Jira ticket, a Slack thread, and a developer’s local environment. Revoking the copy found in one location does not answer the larger identity infrastructure question of “where else did this credential travel before anyone found it?”

That duplication turns remediation into an evidence problem. Security teams need to know whether the exposed credential is unique or repeated, whether every copy has been removed, and whether the issuing system has revoked or rotated the underlying secret. Directories cannot provide that history because the sprawl happened outside the directory.

For a machine, the credential is the identity

For a human identity, the credential and the person stay separable. An identity system can put friction between the two, through multi-factor prompts, device posture, and session or behavior checks, precisely because the human exists apart from whatever token authenticates them. A machine offers no equivalent seam. There is no second factor, and no colleague notices that a login does not look right. Whoever holds a service account’s key is, for every practical purpose, that service account. Access and identity collapse into the same string of characters.

This collapse is the reason the credential plane is critical, not merely a factor that makes directory gaps worse. When a service account key leaks in a public repository, a CI/CD log, or a chat message, the attacker does not exploit a flaw in the directory or the identity provider. They authenticate with a valid credential. RBAC grants the request because the token carries valid privileges, cloud IAM allows the call because the key belongs to an authorized service account, and audit logs record the activity as normal, authorized access. A leaked machine credential with elevated privileges can be difficult to distinguish from legitimate use until the exposure itself is found. That is why this risk has to be met on the credential plane, not in the directory.

Multi-cloud and hybrid infrastructure multiplies credential fragmentation

In hybrid identity infrastructures spanning on-premises Active Directory, Entra ID, AWS IAM, GCP IAM, Kubernetes, and multiple SaaS platforms, credential handling fragments across every layer. Each cloud provider has its own service account and key system, with different rotation and auditing capabilities. Federation through SAML or OpenID Connect links directories to cloud IAM, but does not extend credential visibility into code, pipelines, or collaboration tools. Identity orchestration unifies policy enforcement, but does not surface leaked credentials downstream.

The result: an enterprise can have strong directory governance in Entra ID, mature RBAC in Kubernetes, and comprehensive IAM policy in AWS, and still have exposed credentials in repositories that grant access to all three. A scalable identity infrastructure for multi-cloud environments, machine identity management in multi-cloud environments, and a coherent multi-cloud security architecture all depend on visibility that follows the credential, not the platform.

Compliance requires credential evidence directories do not hold

Frameworks including SOC 2, ISO 27001, PCI DSS, NIST 800-53, DORA and HIPAA all create expectations around identity and access controls, credential management, logging, monitoring, and incident response. PCI DSS 8.6.2 points directly at part of this problem by addressing hard-coded passwords and passphrases for application and system accounts that can be used for interactive login. More broadly, regulated identity programs need evidence that credentials are not just governed in theory, but found, monitored, and remediated when they leak.

Directory systems provide identity lifecycle evidence like provisioning, deprovisioning, and access reviews. They do not provide credential exposure evidence like whether secrets leaked, how long they were exposed, whether they were still valid, and whether they were remediated. This is what makes the credential plane so important.

Securing identity infrastructure: best practices across the planes

For security leaders managing IAM, the practical goal is to keep directory, lifecycle, and access controls strong while adding the credential visibility needed for non-human identities.

Governance plane: directory and lifecycle hygiene.

• Consolidate directories where possible to reduce identity provider sprawl.
• Automate provisioning and deprovisioning through SCIM, IGA workflows, and HR-driven triggers.
• Enforce multi-factor authentication (MFA) and conditional access across human access paths.
• Integrate cloud IAM and Kubernetes RBAC with corporate directories through OpenID Connect or SAML federation, and run regular access certification campaigns.
• Maintain identity infrastructure backup and recovery procedures for directories and identity providers, so restoring identity services never depends on improvisation.

Credential plane: secrets hygiene and exposure evidence.

• Vault long-lived secrets in dedicated systems such as HashiCorp Vault, CyberArk, AWS Secrets Manager, or Azure Key Vault.
• Prefer short-lived, automatically rotated credentials over static keys, and enforce rotation policy.
• Replace hard-coded credentials with vault-backed references, workload identity, or ephemeral credentials wherever possible.
• Set mean time to remediation targets for exposed credentials and wire confirmed findings into incident response.
• Measure vault coverage instead of treating vault adoption as a mandate alone. A vault mandate without measurement is a suggestion; the missing piece in most programs is vault coverage reported as a number.

Enforcement layer: cloud, Kubernetes, and workload identity.

• Use cloud-native workload identity (AWS IRSA, GCP Workload Identity, Azure Managed Identity) to remove static cloud credentials from applications.
• Implement Kubernetes RBAC with a dedicated ServiceAccount per workload, and disable token automounting for pods that do not need API access.
• Adopt identity-native infrastructure access management for servers and internal services: short-lived certificates and SSO-backed sessions instead of static SSH keys.
• Deploy a service mesh with mutual TLS, and enforce identity and credential policy as code (OPA Gatekeeper, Kyverno).
• Scope CI/CD pipeline credentials to short-lived tokens and keep long-lived secrets out of pipeline config.

Zero trust and identity infrastructure 

Zero trust makes identity the enforcement point for every access decision. But those decisions still depend on the integrity of the credential being presented. If a valid machine credential has leaked, the request may pass verification while the underlying access is already compromised. Credential exposure detection protects the trust assumptions zero trust depends on, especially for non-human identities.

Auditing identity infrastructure: proving access control and credential control

Most identity audits start on the governance plane: access reviews, certification campaigns, directory group membership, federation trust, cloud IAM policy, privileged access, identity provider logs, and deprovisioning checks. That work is essential. It tells the organization who should have access, which permissions exist, and whether lifecycle controls are operating as intended.

But governance-plane auditing does not answer the credential questions behind that access: whether a token has leaked, whether a service account key still works, who owns it, where else it appears, or whether remediation can be proven.

Credential-plane auditing fills that gap. It should cover:

• Source code, including full git history, for leaked API keys, tokens, service account credentials, and connection strings.
• CI/CD pipelines for credentials in build output, environment variables, and configuration.
• Collaboration tools such as Slack, Jira, Confluence, and Teams, where credentials are often copied during development, debugging, and incident response.
• Developer endpoints for credentials stored in local files, shell history, CLI configs, IDE caches, browser stores, containers, and AI coding tool artifacts.
• Public repositories for organizational exposure outside the company’s controlled environments.
• Non-human identity credentials, attributed to an owning team wherever possible.
• Exposure metrics including time to detection, time to remediation, exposure window, recurrence, duplication, validity, and vault coverage.

A finding on its own is only a string of characters. The value is the context around it: who likely owns the credential, whether it is still live, whether it appears in multiple places, whether it is covered by a vault, and how urgently it needs to be remediated.

Because GitGuardian sits in the SDLC layer, with more than 500 secrets detectors running across repositories, pipelines, collaboration tools, and developer endpoints, it can add context to credential findings. It also reconciles detected credentials against vaults including HashiCorp, CyberArk, AWS, Azure, Akeyless, and Delinea, reporting vault coverage as a measurable control. Policy still lives in the vault, PAM, and IGA. GitGuardian surfaces the evidence of where reality diverges from it.

Modernizing legacy identity and directory infrastructure

Many enterprises still anchor identity infrastructure on on-premises Active Directory, with layers of LDAP integration, Kerberos authentication, and static service account credentials accumulated over decades. Modernization has to address the systems that govern identity and the credentials that continue to carry access through the environment.

Governance-plane modernization.

• Extend on-premises Active Directory to the cloud through Entra ID, or adopt cloud-native identity providers for new workloads.
• Consolidate fragmented directories into a federated architecture, using identity orchestration to bridge legacy and modern protocols without rip-and-replace migration.
• Implement IGA for automated lifecycle management across hybrid environments.

Credential-plane modernization.

• Inventory the static, long-lived credentials created under legacy infrastructure.
• Move hard-coded secrets into vault-backed storage with automated rotation, and replace long-lived service account keys with workload identity federation.
• Continuously detect legacy credentials that leaked into code and config over years of development.
• Set credential hygiene baselines and track remediation as part of the program.

Every legacy estate has the account nobody dares shut down, because the engineer who understood it left years ago and no one knows what it touches. The blocker is missing evidence, not the directory: what consumes this account, what permissions it holds, and what breaks if it is revoked. Credential-plane visibility surfaces that evidence, so decommissioning stops being a production gamble. The team still executes the change through its own vault and IGA. The difference is a modernization program that is safe to actually finish.

The future of identity infrastructure in 2026 and beyond

• Credential context feeding governance, not merging into it: exposure, ownership, and vault-coverage evidence flowing into the directory, PAM, and IGA systems that already run, so those systems act on ground truth from the engineering layer.
• Non-human identity as a first-class infrastructure concern, with dedicated tooling for discovery, ownership, and risk scoring.
• Workload identity federation replacing static credentials as the default for cloud-native environments.
• Credential exposure evidence becoming a standard compliance expectation, not just a security best practice.
• AI-driven identity analytics: anomaly detection on credential usage and continuous access review. AI agent identities have become one of the fastest-growing parts of the machine identity estate.
• Decentralized identity and verifiable credentials beginning to shape enterprise design.

The next stage of identity infrastructure depends on evidence as much as enforcement, giving teams a reliable way to know which credentials exist, where they are exposed or mismanaged, who owns them, whether they still work, and whether the controls already in place actually cover them.

Want to see how the evidence layer works alongside your directory, vault, and IGA? Try GitGuardian for free or book a demo.

FAQs