Beyond Password Managers: How to Minimize Secret Exposure

TL;DR — The safest secret is one that does not exist. The next best option is short-lived, narrowly scoped, and unavailable for a person to copy. A password manager remains valuable, but it should be the fallback for systems that still require static passwords—not the foundation of production access.

Password managers solve an important problem: they let us generate and store unique credentials instead of remembering or reusing them. What they do not solve is the more fundamental problem that a long-lived credential exists, can be used repeatedly, and may grant more access than its holder needs.

For an engineer, the stronger design is not simply a better vault. It is an identity and access system in which people and services rarely receive secrets at all. They receive a specific capability, temporary role, or mediated session instead.

This distinction matters because human authentication and machine authentication are different problems. Passkeys can replace passwords for a person signing in. Workload identity, dynamic credentials, and access brokers address API keys, database passwords, cloud credentials, and production sessions.

What is stronger than a password?

There is no single replacement for every password. The preferred mechanism depends on who is authenticating and what they need to do:

1. Workload or managed identity lets software authenticate without a stored API key.
2. Short-lived certificates and tokens expire after minutes or hours and are limited to a specific role.
3. Passkeys and hardware security keys provide phishing-resistant authentication for people.
4. Dynamic secrets are created immediately before use and revoked automatically.
5. Static credentials in a password manager remain the compatibility option for systems that support nothing better.

The first four approaches reduce either the existence, visibility, lifetime, or authority of a secret. A password manager primarily reduces the risk of weak storage and password reuse. Both are useful, but they operate at different layers.

Use passkeys for people

A passkey uses a public-private key pair instead of sending a shared password to a server. The private key remains with the authenticator, and the credential is bound to the legitimate relying-party domain. That makes a correctly implemented WebAuthn or FIDO2 login resistant to conventional credential phishing.

NIST SP 800-63B explicitly states that passwords and manually entered one-time passwords are not phishing-resistant. NIST’s highest authentication assurance level requires phishing-resistant public-key authentication, with non-exportable keys protected by hardware. The FIDO Alliance overview of passkeys explains the underlying key-pair model.

There are two useful forms:

• Synced passkeys are convenient and recoverable across devices. Their security also depends on the account and synchronization system that carries them.
• Device-bound hardware security keys keep private keys non-exportable. They are a better fit for primary email, cloud administration, source control, and other high-impact accounts.

For important accounts, register at least two hardware keys: one for daily use and one stored separately for recovery. Account recovery deserves the same care as normal authentication because a weak recovery process can bypass a strong passkey.

Remove credentials from workloads

An application should not need a permanent cloud access key merely because it needs to call an API.

Cloud platforms provide identities tied to a runtime, virtual machine, container, or external workload. The workload proves where it is running and receives temporary credentials for an assigned role. The application no longer needs a key in a configuration file, repository, deployment variable, or developer’s vault.

The major cloud platforms document this pattern:

• AWS recommends temporary credentials and IAM roles instead of long-term access keys.
• Azure managed identities remove the need for developers to manage credentials for supported resources.
• Google Cloud Workload Identity Federation lets external workloads exchange their existing identity for short-lived Google Cloud credentials.

For infrastructure that spans platforms, SPIFFE defines a standard workload identity carried in short-lived certificates or tokens. Keys and certificates can be rotated automatically without embedding an authentication secret in the application.

This is stronger than protecting an API key well. It eliminates the API key.

Prefer dynamic credentials to static secrets

Some systems still require a database username, certificate, or token. In that case, create the credential on demand and give it a short time to live.

A dynamic database credential might be:

• unique to one workload or access request;
• restricted to a read-only database role;
• valid for 30 minutes; and
• revoked automatically when the lease expires.

If it is exposed, its useful lifetime and blast radius are much smaller than those of a shared production password. HashiCorp’s comparison of static and dynamic secrets shows how a secrets broker can generate unique credentials only when they are requested.

Short-lived does not mean harmless. A token valid for 30 minutes can still do damage during those 30 minutes. Its permissions must be narrow, and revocation must work promptly.

Grant an action, not access to a secret

For production access, a useful architecture looks like this:

Hardware-backed passkey
          |
          v
Corporate identity provider and SSO
          |
          v
Access request with a reason and approval
          |
          v
Just-in-time role with a short expiry
          |
          v
Access proxy or privileged access broker
          |
          v
Temporary certificate, token, or injected credential
          |
          v
One specific server, database, or cloud role

The engineer receives a connection or an allowed operation, not a password that can be copied into another tool.

Credential injection is useful for legacy targets. An access proxy retrieves or creates the credential and presents it to the target on the user’s behalf. The user does not receive the credential directly. HashiCorp Boundary, for example, documents this distinction in its credential management model.

There is an important limit: hiding a credential does not prevent misuse of an authorized session. If an engineer receives an unrestricted root shell, that shell remains powerful even when its password is invisible. The session must also be constrained by resource, role, permitted operations, time, and approval.

Apply the model to common engineering workflows

Cloud console and command-line access

Authenticate through SSO with a passkey, then assume a temporary cloud role. Avoid individual IAM users with permanent access keys. Separate read-only, deployment, and administrative roles rather than giving every engineer the same production permissions.

CI/CD

Use the CI provider’s OIDC identity to request a short-lived deployment role. Do not store a permanent cloud key in repository or CI secrets when federation is available. Restrict the trust policy to the expected repository, branch, workflow, environment, and audience.

Servers and SSH

Issue short-lived SSH certificates after an access request instead of distributing permanent private keys. Require a stronger approval path for production administration and record high-risk sessions where appropriate. For systems that cannot use certificates, protect the SSH private key with a hardware token and avoid sharing one key across machines.

Databases

Prefer identity-aware database authentication or dynamically generated users. Give each session a specific database role and a short expiry. Application access and human troubleshooting access should use separate identities.

Applications and Kubernetes

Assign a separate workload identity to each service. Do not reuse one service account or API token across unrelated applications, clusters, or environments. Where the destination cannot accept workload identity directly, let a broker exchange it for a short-lived destination credential.

Legacy APIs and websites

Some systems expose only a static API key or password. Store that credential in a dedicated secret or password manager, scope it to one service and environment, and inject it at runtime. Disable human read or export access when the platform allows it.

For an ordinary website that still requires a password, use a unique generated password, autofill it only on the matching domain, and add a FIDO2 security key or passkey as the second factor.

Build around zero standing privilege

The operational goal is zero standing privilege: nobody keeps production administrator access merely because they may need it later. Privilege is activated for a specific reason and expires automatically.

A practical policy should cover:

• Identity: individual human and machine identities; no shared accounts.
• Scope: one environment, service, resource, and role per grant.
• Time: just-in-time access with a 15–60 minute default for production.
• Visibility: no routine read, list, clipboard, or export permission for production secrets.
• Approval: a second person for destructive, root, or emergency access.
• Device trust: privileged access only from managed, encrypted, monitored devices.
• Audit: record the requester, approver, reason, ticket, target, role, session start, and expiry.
• Separation: different identities and credentials for development, staging, and production.
• Revocation: terminate the role and session promptly, not merely at the next password rotation.
• Recovery: keep break-glass access separate, alert on every use, and rotate it immediately afterward.

The OWASP Secrets Management Cheat Sheet provides a broader lifecycle reference covering least privilege, creation, rotation, revocation, expiration, auditing, and the handling of plaintext secrets.

A practical setup for one engineer

An individual engineer or small team does not need to implement every control at once. A reasonable progression is:

1. Keep a password manager for legacy passwords, recovery codes, license keys, and unavoidable static credentials.
2. Register a primary and backup FIDO2 hardware key on email, source control, cloud accounts, and the password manager itself.
3. Choose passkeys instead of passwords whenever a service supports them.
4. Replace cloud access keys with SSO, assumed roles, and temporary credentials.
5. Replace CI/CD cloud secrets with OIDC federation.
6. Move production SSH and database access to short-lived certificates or dynamic credentials.
7. Give services workload identities instead of copying secrets into configuration files.
8. Put any remaining static production secret behind a broker, with one consumer, one environment, narrow permissions, rotation, and audit.

Start by inventorying existing secrets: who owns each one, who consumes it, where copies exist, what it can do, and how it is revoked. Classify each secret as removable, replaceable with federation, replaceable with a dynamic credential, or temporarily unavoidable. Migrate the highest-impact production and CI/CD credentials first.

The destination is not a more elaborate collection of well-hidden passwords. It is an environment in which permanent production secrets are rare, people do not see them, and every privileged capability is short-lived, narrow, and auditable.