Secrets & Key Management

In 2022, a developer at a major financial services firm pushed code to a public GitHub repository. Buried inside was an API key , a secret that should have lived in a vault, not a version control system. Within minutes, automated scanners operated by threat actors had found it, and within hours it was being used to exfiltrate data from a cloud environment the developer had no idea was exposed. The key had been sitting in the codebase for months. Nobody had noticed. The breach was not sophisticated , it was entirely avoidable. That is the secrets management problem in its most common form: not a clever attack, but an unguarded door that nobody remembered leaving open.

What is Secrets & Key Management, Really?

Secrets management is the discipline of controlling how sensitive credentials , API keys, passwords, certificates, encryption keys, tokens, and connection strings , are created, stored, distributed, used, and retired. It sounds like a straightforward IT hygiene problem, and that is exactly why it is so consistently underestimated. In practice, secrets are the skeleton keys of a modern enterprise. A secret that falls into the wrong hands does not trigger an alarm. It just works , silently, with full authorization, indistinguishable from legitimate access.

The traditional approach treated secrets like passwords: create them, share them with whoever needs them, and occasionally remember to change them. That model collapsed under the weight of cloud infrastructure, microservices, and automation. A modern enterprise can have tens of thousands of secrets in active use , not just for humans, but for machines. Every CI/CD pipeline, every containerized service, every third-party integration runs on credentials of some kind. Most of those credentials were created under time pressure, stored wherever was convenient, and never formally tracked.

What makes this genuinely complex is the intersection of secrets with machine identities. Human users authenticate interactively , they log in, get challenged, their behavior can be monitored. Machine identities authenticate silently and continuously, often with broader permissions than any individual human user and with no MFA equivalent standing between them and sensitive systems. When a vendor's integration runs in your environment using a long-lived API key with admin-level scope, that key is effectively an always-on privileged session.

Secrets risk breaks down across several distinct failure modes:

• Hardcoded secrets , credentials embedded directly in source code or configuration files, often committed to version control
• Secrets sprawl , the same credential copied across multiple systems and teams, making rotation practically impossible
• Stale credentials , keys provisioned for a specific purpose and never retired, accumulating risk indefinitely
• Overprivileged secrets , credentials scoped with far more access than required, maximizing blast radius on compromise
• Unmonitored usage , secrets in active use with no logging or alerting, so unauthorized use goes completely undetected

Why this matters

Vendor integrations run almost entirely on secrets. Every API connection a vendor has to your environment is authenticated by a credential of some kind. In many organizations those credentials were provisioned at the start of the vendor relationship and have never been reviewed since. They may have been shared with multiple people at the vendor, stored in the vendor's own systems with governance standards you have never assessed, and scoped with permissions that have since expanded far beyond the original use case.

The third-party dimension creates a specific accountability gap. When a secret lives inside your own environment, you have the theoretical ability to monitor its usage, rotate it on a schedule, and revoke it if something looks wrong. When a secret has been handed to a vendor, those controls depend entirely on the vendor's own practices , practices you likely assessed once during onboarding and have not revisited. If the vendor stores your API key in a plaintext config file and shares it across their engineering team, you have no visibility into any of that.

From an attacker's perspective, vendor-held credentials are an attractive target precisely because they tend to be long-lived, broadly scoped, and poorly monitored. A threat actor who compromises a vendor's environment and finds an API key to your production systems does not need to defeat your perimeter controls. They already have a credential your systems will treat as fully legitimate.

Where most teams get this wrong

The most common failure is treating secrets management as a one-time provisioning exercise rather than an ongoing governance discipline. Credentials are created, handed to vendors, and promptly forgotten. Nobody owns the lifecycle. Nobody tracks what was issued to whom, when it was last rotated, what scope it carries, or whether it is still in active use. The second failure is assuming that limiting distribution is the same as managing access. Sending an API key to one person at a vendor via encrypted email feels secure. It is not a secrets management program.

• API keys issued to vendors with no expiry date and no rotation schedule
• Shared credentials used by multiple people at the vendor, destroying any hope of attributing activity to an individual
• No inventory of what secrets exist, what systems they access, and which vendors currently hold them
• Secrets provisioned for a specific project that outlive the project by months or years
• No alerting when a secret is used outside of expected patterns

What good looks like

Mature secrets management treats every credential as a time-limited, purpose-scoped, individually attributed token , not a shared password that gets passed around. The goal is that no secret should exist indefinitely, carry more privilege than the task requires, or have its usage be invisible.

• Centralized secrets vaults where all credentials are stored, versioned, and access-controlled , nothing lives in config files or spreadsheets
• Automatic rotation on a defined schedule , or dynamic secrets that are generated on demand and expire after use
• Least-privilege scoping on every credential , vendor API keys can only do exactly what the integration requires
• Full audit logging of every secret access event , who retrieved it, when, from where
• Automated revocation workflows tied to vendor offboarding , credentials revoked within hours, not months
• No human-readable secrets in transit , vendors authenticate through short-lived tokens, never receiving a static key they store themselves

Tooling

Secrets Vaults , HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager

Enterprise standard for centralized credential storage with versioning, access policies, audit logs, and rotation automation. A vendor using one of these platforms for your credentials is in a fundamentally different risk position than one using a config file. The key question: are your credentials specifically stored in it?

Dynamic Secrets , HashiCorp Vault Dynamic Secrets, AWS IAM Roles Anywhere

Dynamic secrets are generated on demand and automatically expire , eliminating long-lived credentials entirely. A vendor integration using dynamic secrets cannot leak a persistent key because no persistent key exists. This is the gold standard for third-party access.

Secrets Scanning , GitGuardian, Trufflehog, GitHub Advanced Security

These tools continuously scan code repositories and pipelines for exposed secrets. A vendor who has never scanned their repositories may be sitting on exposed credentials they do not know about , including yours.

Privileged Access & Credential Brokering , CyberArk, BeyondTrust, Delinea

These platforms broker access without ever exposing the underlying secret. The vendor authenticates to the broker, which establishes the session on their behalf. The vendor never sees the actual credential.

Cloud-Native Identity , AWS IAM, Azure Managed Identities, GCP Workload Identity

For cloud-to-cloud integrations, these eliminate static API keys entirely. A vendor's workload authenticates using a managed identity with permissions you define and can revoke instantly. Increasingly the expected standard for mature vendor relationships.

Governance challenges

The governance gap in secrets management is almost always an ownership problem. Nobody disagrees that credentials should be rotated, scoped, and monitored. The disagreement , usually unspoken , is about whose job that is. Secrets issued to vendors fall into a category that nobody actively manages because no one specifically owns it.

• Maintain a secrets inventory , every credential issued to a vendor documented with scope, issue date, rotation schedule, and named owner
• Tie credential revocation to contract and access reviews , not just offboarding, but any material change in the vendor relationship
• Set maximum credential lifetimes in vendor contracts , 90 days is a reasonable baseline; some environments warrant shorter
• Require vendors to store your credentials in a named, auditable secrets management solution , not a config file, not a shared password manager with no audit trail
• Alert on anomalous credential usage , unusual call volumes, off-hours access, unexpected source IPs

If you are a small team

Start with inventory , you cannot manage what you cannot see. Spend one week cataloguing every credential your organization has issued to a third party: what it accesses, when it was issued, when it was last rotated, and who at the vendor is using it. That exercise alone will surface stale credentials, overprivileged keys, and forgotten integrations.

• Revoke any credential that has not been used in 90 days , if nothing breaks, it was not needed
• Replace shared credentials with individual, named credentials immediately
• Set calendar reminders for rotation on every active vendor credential
• Ask every vendor: where specifically are you storing the credentials we issued you?

What to require

Ask directly:

"Where and how are the credentials you use to access our environment stored? Are they in a secrets vault, and if so, which one?"

"What is your rotation policy for API keys and credentials issued by your customers? How is that enforced?"

"How do you ensure credentials we issue are used only by authorized individuals , and what happens to them when a team member leaves?"

Expect as evidence

• Named secrets management platform with documented access controls and audit logging
• Rotation policy with a defined maximum credential lifetime , ideally 90 days or less
• Process for immediate revocation when personnel with access depart
• Evidence that credentials are scoped to the minimum required permissions for the integration

If a vendor describes storing your credentials in a config file, a shared team password manager, or a spreadsheet , treat that as a material risk finding regardless of how well they perform on every other control.

How to evidence it

PCI-DSS, SOC 2, and ISO 27001 all include controls around credential management. The expectation is that you can demonstrate the policy is being applied to third-party credentials specifically , not just internal ones.

• Documented inventory of all credentials issued to third parties, including scope and rotation history
• Evidence of periodic access reviews that specifically cover vendor-held credentials
• Documented revocation records for all credentials issued to vendors whose relationships have ended
• Contractual clauses requiring vendors to store credentials in approved secrets management solutions

Key Takeaway

Secrets are not just a technical problem , they are a governance problem dressed in technical clothing. The organizations that manage this well treat every credential as a liability with an owner, an expiry, and an audit trail. In the third-party context, every key you issue to a vendor is a door into your environment that someone else is holding. You do not get to choose how carefully they guard it , but you do get to choose how long it stays open, how much it unlocks, and whether you are watching when it is used.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations