Beyond Password Managers: How to Minimize Secret ExposureSkip to article

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

Password managers solve an important problem: they let us generate and store<br>unique credentials instead of remembering or reusing them. What they do not<br>solve is the more fundamental problem that a long-lived credential exists,<br>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<br>identity and access system in which people and services rarely receive secrets<br>at all. They receive a specific capability, temporary role, or mediated<br>session instead.

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

What is stronger than a password?

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

Workload or managed identity lets software authenticate without a<br>stored API key.

Short-lived certificates and tokens expire after minutes or hours and<br>are limited to a specific role.

Passkeys and hardware security keys provide phishing-resistant<br>authentication for people.

Dynamic secrets are created immediately before use and revoked<br>automatically.

Static credentials in a password manager remain the compatibility<br>option for systems that support nothing better.

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

Use passkeys for people

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

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

There are two useful forms:

Synced passkeys are convenient and recoverable across devices. Their<br>security also depends on the account and synchronization system that carries<br>them.

Device-bound hardware security keys keep private keys non-exportable.<br>They are a better fit for primary email, cloud administration, source<br>control, and other high-impact accounts.

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

Remove credentials from workloads

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

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

The major cloud platforms document this pattern:

AWS recommends temporary credentials and IAM roles<br>instead of long-term access keys.

Azure managed identities<br>remove the need for developers to manage credentials for supported<br>resources.

Google Cloud Workload Identity Federation<br>lets external workloads exchange their existing identity for short-lived<br>Google Cloud credentials.

For infrastructure that spans platforms,<br>SPIFFE defines a standard<br>workload identity carried in short-lived certificates or tokens. Keys and<br>certificates can be rotated automatically without embedding an authentication<br>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<br>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...