What Is Secrets Management? Keeping API Keys, Tokens And Passwords Out Of Attackers' Reach

Secrets management is how an organisation creates, stores, hands out, rotates and revokes the credentials that software uses to talk to other software. These include API keys, database passwords, cloud access keys, certificates, tokens and SSH keys. Good secrets management keeps those values out of code, files and chat. It gives each one an owner and an expiry date, and it records who or what used it. Better still, it replaces stored secrets with identities wherever possible, so there's nothing to steal.

This guide covers what counts as a secret, where they leak, how secrets management works in practice, with Microsoft Azure examples, and what to do when one gets out.

What counts as a secret?

• API keys for SaaS platforms, payment providers and AI model providers.
• Database connection strings and service account passwords.
• Cloud credentials: access keys, service principal client secrets, storage account keys and shared access signatures.
• Tokens: personal access tokens for source control, CI/CD tokens and webhook signing secrets.
• Keys and certificates: SSH private keys, TLS private keys and code-signing keys.

What they have in common: anyone holding the value can act as the system it belongs to, usually with no MFA and often with no expiry.

Where secrets leak

On penetration tests, we rarely need an exploit to find credentials. We look where people put them. These are the places that turn up most often:

• Source code and commit history. A key removed in the latest commit is still in the history, and in every clone and fork.
• .env and config files on developer machines, build servers and file shares.
• CI/CD logs that print environment variables or commands during a failed build.
• Container images with keys baked into a layer during the build.
• Scripts and scheduled tasks on servers, with passwords written straight into them.
• Wikis, tickets, Teams chats and SharePoint documents where someone pasted a key "just for now".
• Developer workstations, which hold cloud CLI credentials, source control tokens and AI tool tokens side by side.

Attackers know this list too. Infostealers and supply chain malware collect exactly these files. In October 2026, a hijacked release of a popular Python library ran a collector that went through cloud credentials, .env files, SSH keys and CI configuration on every machine that started Python. We break that down in our threat research post.

How secrets management works

1. Eliminate the secret where you can

The best secret is one that doesn't exist. In Azure, managed identities let a VM, App Service, Function or container authenticate to Key Vault, Storage, SQL and Azure AI services using Entra ID, with no password or key to store. Workload identity federation does the same for pipelines and Kubernetes workloads: the platform proves who it is with a short-lived token, and Entra ID trusts that proof instead of a client secret.

2. Store the rest in a vault

Secrets that must exist, such as third-party API keys, belong in a dedicated vault such as Azure Key Vault. A vault gives you:

• Encryption at rest, with keys protected by hardware security modules on higher tiers.
• Access control per secret or per vault, ideally through Azure RBAC and managed identities.
• An audit log of every read, which you can send to Microsoft Sentinel.
• Versioning and expiry dates.
• Private network access, so the vault isn't reachable from the internet.

Applications fetch the value at run time instead of carrying it in a file.

3. Scope each secret tightly

One key per application and environment, with the least access it needs. A shared "integration key" used by six services can't be rotated without breaking all six, and nobody knows which use is legitimate.

4. Rotate on a schedule

Set an expiry on every secret and rotate before it's reached. Automate rotation where the service supports it. Rotation limits how long a leaked value is useful, and practising it means you can do it quickly when you have to.

5. Scan for leaks

Turn on secret scanning in your source control platform, and push protection if it's available, so a commit containing a key is blocked before it lands. Scan container images and CI logs too. Microsoft Defender for Cloud's DevOps security features can surface exposed secrets in connected repositories.

6. Watch how secrets are used

Send vault access logs and service principal sign-ins to your SIEM. A secret read by an identity that has never read it before, or a service principal signing in from a new network, is often the first sign of a leak.

What to do when a secret leaks

1. Revoke or rotate it first. Deleting the file or the commit doesn't help. The value may already have been copied.
2. Find out what it could reach and over what period.
3. Check usage in the target system's logs from the time of exposure onwards. For Entra ID service principals, review AADServicePrincipalSignInLogs for unfamiliar IP addresses.
4. Look for persistence. Attackers who used a key may have created new keys, users or app credentials.
5. Fix the cause: move the secret into a vault or replace it with a managed identity, so it can't happen the same way again.

Common mistakes

• Treating secrets as a developer problem instead of an identity problem.
• Client secrets on app registrations set to the maximum lifetime and forgotten.
• One vault for everything, with broad read access granted to everyone.
• Copying secrets out of the vault into pipeline variables, which recreates the problem the vault was meant to solve.
• No inventory, so nobody knows which secrets exist until one leaks.

Frequently asked questions

Is a password manager the same as secrets management?

Not quite. A password manager stores credentials that people use. Secrets management covers credentials that software uses, retrieved by applications at run time, with rotation and machine-to-machine access control. Many organisations need both.

Are environment variables safe for secrets?

They're better than hard-coding, but anything that can read the process environment or the .env file can read them, including malware on the same host. Use them to point at a vault or a managed identity, not to hold long-lived keys.

How often should secrets be rotated?

It depends on the risk and the service, but set an expiry on every secret, rotate high-value ones more often, and rotate immediately on any suspicion of exposure. Short-lived tokens issued through managed identities make most scheduled rotation unnecessary.

What is secrets sprawl?

The same credentials copied into many places: repos, pipelines, laptops, wikis. Each copy is another chance to leak, and sprawl makes rotation painful. Central vaults and identities reduce it.

How Wizard Cyber can help

Our offensive security team finds exposed secrets the way an attacker would, and our consultants help move applications onto managed identities and Key Vault without breaking them. Once that's done, our 24/7 SOC watches vault access and service principal sign-ins in Microsoft Sentinel, which we've run since 2019.

To see how that would work for your environment, talk to us or book a demo.