Stop Asking Users to Remember Secrets

The engineer sitting next to me could recite the memory ordering guarantees of the Java Memory Model from memory. She had, that same week, correctly diagnosed a race condition that three other people had looked at and missed. And she could not log into the payroll portal.

She tried four things. Each of them was a variation on a theme — a base word she clearly used elsewhere, with different digits and a different symbol on the end. Each of them failed. She reset the password, chose a fifth variation, and told me, without irony, that she would be doing this again next quarter.

I went looking at the reset data afterwards, because it seemed like it might be a training problem and I wanted to know who needed training. It wasn't. The strongest signal in the reset queue had nothing to do with role, seniority, or whether someone had completed the security awareness module. It was the interval since that user's previous login to that specific system. Systems people used daily produced almost no resets. Systems people touched once a quarter produced almost all of them. The people resetting passwords on the quarterly systems were the same people who never reset them on the daily ones.

That is not a discipline gradient. That is a component behaving exactly the way its datasheet says it will.

Human memory is a storage component with published, stable, well-characterised properties: small durable capacity, retrieval that decays without rehearsal, interference that rises with the similarity of stored items, and — critically for us — no rate limiting, no revocation, no rotation, and no audit trail. Designing a system that asks that component to hold high-entropy, non-reusable, per-site values is a specification error, not a user failure. It is the same error as specifying microsecond latency from a spinning disk. And the entire modern authentication stack — password managers, passkeys, hardware keys, device-bound credentials, and, less obviously, single sign-on — is one architectural move repeated: relocate the secret to storage built to hold it.

The interesting part isn't that move; most engineers have made it. The interesting part is what the relocation creates, and the fact that memory never actually leaves the system. It survives in the master password, the device PIN, and the recovery flow. So the real design question is not "how do we eliminate memorised secrets" — you can't — but how many memorised secrets does a person have, and what does each one unlock? That reframing is where this article is going, and it has a consequence most people haven't articulated: a six-digit PIN is a perfectly good memorised secret and an eight-character password is a catastrophic one, for reasons that have nothing to do with the number of bits.

Scope, because there are neighbours: I'm not re-deriving password entropy — Longer Beats Complex does that with the actual math — and I'm not doing policy history, which is The Password Policy Arms Race. This is about memory as a component, and about relocation as an architectural pattern.

The datasheet

We talk about human memory in authentication as if it were a black box with a quality knob labelled "user discipline." It isn't. It's one of the most heavily studied systems in science, and while the cognitive literature is genuinely contested on mechanism, the engineering-relevant behaviours are not seriously in dispute. Here is what you're specifying against.

Durable capacity is small, and the useful number is smaller than you think. The famous figure — Miller's "seven, plus or minus two," from 1956 — is about working memory, the scratchpad, and it isn't even the right number any more; subsequent work generally puts the capacity of unstructured working memory lower, around four items. Neither number is the constraint that matters here. The constraint is the number of arbitrary, meaningless, mutually-confusable strings a person can retrieve reliably on demand, months apart, without a cue. That number is not seven. Under favourable conditions — deliberate rehearsal, spaced practice, meaningful structure — people can hold a handful. Ask them to hold fifty and you are not asking for a harder version of the same thing; you are asking for a different thing entirely, and it doesn't work at any level of effort.

The mitigation memory actually offers is chunking: arbitrary material becomes retrievable when it can be attached to structure the person already has. This is why passphrases work better than character soup, and it's also precisely why they leak entropy — the same structure that makes a phrase memorable makes it predictable, which is the argument the entropy article makes at length. Memorability and unpredictability are not independent variables you can optimise separately. They are in direct tension, because they are both functions of how much existing structure the item shares with the rest of the world.

Retrieval decays without rehearsal, and the decay is steep early. Ebbinghaus described the shape of this in the 1880s and the qualitative finding has survived a century of replication and refinement: the probability of successful retrieval drops sharply in the first days after learning and then flattens, and each successful retrieval flattens the curve further. The engineering consequence is the one my reset queue was showing me. Rehearsal frequency is the dominant variable in whether a memorised secret survives, and login frequency is the rehearsal schedule. You do not choose that schedule. Your users' work does.

Now overlay the thing that makes this genuinely perverse: login frequency is often inversely correlated with account value. The account someone uses forty times a day is their laptop. The accounts they touch twice a year are the retirement provider, the tax portal, the domain registrar that quietly controls every DNS record the company owns, and the root account of the cloud tenancy. The rehearsal schedule is strongest exactly where the stakes are lowest, and weakest exactly where a compromise is unrecoverable. Any system that leans on memory has this inversion built in, and no amount of policy touches it.

Interference scales with similarity, and we manufacture similarity deliberately. This is the property I find engineers have least internalised, and it's the one that explains my colleague's four failed attempts. Memory does not fail by dropping items cleanly; it fails by confusing them. Two stored items compete at retrieval in proportion to how much they resemble each other and how much they share a retrieval cue. Summer2023! and Summer2024! are nearly the worst possible pair of items to ask a person to keep distinct: near-identical surface form, near-identical cue ("the work password"), differing in exactly the position that carries no meaning.

And here is the part that should bother you. Every password policy we have ever written produces that pair. Uniqueness requirements say "make them different"; the cheapest way for a human to make fifty items different is to keep a stem and vary a suffix, which maximises interference. Rotation requirements say "make it different from the last one," which generates a time-series of maximally-confusable variants of a single item — that's the mechanism behind the transformation chains described in The Great Password Myth: Forced Rotation, and it's a memory-interference story as much as it's a cracking story. The policy is not merely failing to help. It is issuing an instruction that the component is architecturally worst at executing.

And then the four properties that have no analogue in the memory literature at all, because they only become visible when you think of memory as infrastructure:

Memory cannot be rate-limited. Every other credential store in your architecture throttles guessing. A secure element enforces an attempt counter in hardware. A login endpoint has a rate limiter in front of it. A vault has a KDF with a tuned work factor. Memory has none, and it doesn't need any — because the attack on a memorised secret does not happen against the human. It happens against a verifier, offline, at whatever rate the attacker's hardware allows. The reason human-chosen secrets are dangerous is not that memory is a weak store. It's that memory's output gets copied into a verifier that an attacker may eventually hold, and at that moment the entropy of a human choice is measured against a GPU. Hold on to that sentence; the whole final third of this article turns on it.

Memory cannot be revoked. You can invalidate a session, rotate a key, revoke a certificate, and wipe a device. You cannot make a person stop knowing something. When you force a reset after a breach, you have reset the verifier; the human still holds the compromised string, and the honest expectation is that it reappears — on a personal account, on a system you don't operate, as the stem of the next variant. A credential store you cannot clear is a credential store that leaks forward in time, indefinitely.

Memory cannot be rotated on your schedule, only degraded on it. Rotation of a stored key is a mechanical operation with a defined cost. Rotation of a memorised item costs a relearning cycle and destroys the rehearsal history that made retrieval reliable. That's why the observed response to rotation is a minimal transformation: it's the only strategy that preserves the retrieval cue.

Memory has no audit trail. You cannot ask it what it holds, when the item was last accessed, or whether it has been copied. Every other secret store in your system can be inventoried. This one is opaque by construction, which means the population of memorised secrets in your organisation — how many, how reused, how strong — is unmeasurable except by proxy. Most security programmes are quietly making load-bearing assumptions about a component they cannot query.

Users are not the enemy, and haven't been since 1999

The framing above is not new, and it's worth naming its lineage, because the field keeps rediscovering it.

Angela Sasse and Anne Adams published "Users Are Not the Enemy" in 1999 — a paper whose central finding was that users circumvented password mechanisms not out of laziness but because the mechanisms were incompatible with getting work done, and that the security community's response was to blame the users rather than revise the mechanism. It is twenty-five years old and reads like it was written about last quarter's policy review.

The strand of work that followed added the piece I find most useful for architects: the idea of a compliance budget — that any individual has a finite capacity for security effort, that the capacity is consumed by every control you impose, and that once it's exhausted, the next control doesn't get partial compliance, it gets circumvention. That is a systems statement, not a psychological one. It means security controls are coupled: the password policy you tighten is spending budget that your phishing reporting, your MFA prompts, and your data handling rules also need. Teams routinely add controls as if the budget were infinite, then treat the resulting workarounds as a discipline problem.

Joseph Bonneau and colleagues gave the field its other durable tool in 2012 with "The Quest to Replace Passwords," which evaluated authentication schemes against a fixed set of usability, deployability, and security criteria rather than arguing about them. The result that everyone remembers is that no scheme dominated passwords on all three axes, which was widely read as a defence of passwords. Read more carefully, its usability axis includes properties like memorywise-effortless and scalable-for-users — and passwords fail both, explicitly and by construction. The framework's real contribution was to make it possible to say "this scheme is worse on deployability and better on memory load" as a factual claim instead of a preference.

The reason I'm citing thirty years of work rather than making the argument fresh is that the conclusion is stable and the industry's behaviour is not. We know memory is the wrong component. We keep specifying it anyway, because it is free at the point of issue — no enrolment, no hardware, no support cost until the reset. The Password Policy Arms Race is the story of forty years spent trying to make the wrong component perform, one rule at a time.

One move, five names

Here is the thing that took me longer to see than it should have. Password managers, passkeys, hardware security keys, device-bound credentials, and single sign-on are usually discussed as five different technologies at different points on a maturity curve. Architecturally they are one move.

Take the secret out of the human and put it in something built to hold secrets. That's it. Everything else is a variation on what the "something" is and how the human proves they're allowed to use it.

Read the second column: five different storage substrates. Read the third: in every single case the human's remaining job is unlocking, not remembering the secret itself. The human went from being the storage to being one factor in the access control on the storage. That's the whole transition, and it's why arguing about manager-versus-passkey as if they were opposed misses that they are the same architectural decision with different trade-offs on portability, phishing resistance, and vendor dependency.

Two of these deserve a note.

Federation is the oldest and least-credited memory relocation technology we have. We justify SSO on operational grounds — one credential store, central revocation, one place to implement MFA — and those are the right reasons. But look at what it does to the human component: it takes an employee who needed sixty memorised secrets and gives them one. Before we had a single technology aimed at password memorability, we had a technology that reduced the count by a factor of sixty, and we sold it as an IT efficiency measure. Reducing the number of memorised items is not a side effect of SSO; it is, in memory terms, the main effect. I've never seen it in an SSO business case.

Passkeys are the only entry that changes the kind of secret, not just its location. A manager still stores a shared secret; the verifier still holds something worth stealing. A passkey stores a private key whose public half is all the verifier ever sees. That's a categorical difference and it's the substance of Why Passwordless Isn't About Convenience — the relocation removes the memory problem, and the change of kind removes the breach and phishing problems. Two independent wins, frequently conflated. The Magic Behind Passkeys covers the mechanics; the relevant point here is that relocation alone would still leave you with a stealable verifier.

Note also what the table doesn't contain: any entry where the human's job got harder. Every one of these is a reduction in what memory is asked to do. That's not a coincidence. It's what progress in this field has consisted of.

What relocation creates

If the article stopped there it would be a slide deck. The engineering content is in the second-order effects, and there are four, all of them real, none of them fatal.

1. Concentration

You have taken fifty independent failure domains and made one. Compromise a vault and you have compromised every account in it. Compromise a device keystore and you have compromised every passkey on it. This is the objection everyone raises first, and it deserves a serious answer rather than a dismissal.

The serious answer is that the objection is arithmetically wrong in the common case and right in the tail, and you should know which one you're in.

It's wrong in the common case because the fifty independent failure domains were never independent. Reuse correlated them: one breach at a forum you forgot about compromises the bank, which is the entire economics of credential stuffing. Fifty accounts protected by three distinct reused passwords is not fifty failure domains, it's three — and three badly protected ones, verified by whichever of the fifty sites had the worst hashing. Consolidating into one vault protected by a strong KDF, rate-limited unlock, and no reuse is a reduction in aggregate risk even though it looks like an increase in blast radius. That trade — many weak correlated domains for one strong domain — is the same trade you make when you put all your production data behind one well-run IAM boundary instead of fifty ad-hoc ones.

It's right in the tail because the consequence distribution changes shape. Before, the bad day was "one account taken over." After, the bad day is "everything, at once." Expected loss went down; variance went up. If your organisation cannot survive the tail — and for some accounts, like the domain registrar or the root of your cloud tenancy, nothing else matters — then the correct response is not to reject relocation but to stop putting those credentials in the same domain as everything else. Separate vault, separate hardware key, separate everything. Concentration is a tool you apply deliberately, per blast radius, not a property you accept globally.

The other half of the answer is the one people forget: the relocated store is auditable and revocable, and memory is neither. A vault can tell you when it was last unlocked, from where, and what was read. A device keystore attests to its own properties. If a vault is compromised you can rotate everything in it in an afternoon, mechanically. A compromised memory has no such affordance. Concentration bought you observability over a component that had none, and that's worth more than the blast-radius argument costs.

2. Sync and portability

Humans have more than one device and replace them unpredictably. So every relocation grows a replication problem within about a year of shipping, and the replication channel — not the store — becomes the interesting security boundary.

This is where the honest complexity lives. A synced vault or a synced passkey means the secret exists in at least three places: two devices and whatever moved it between them. The vendors that do this properly build an end-to-end encrypted key hierarchy where the sync service holds ciphertext it cannot read, and the root of that hierarchy is derived from — here it comes — something the user memorises or a device they already possess. The sync design is where you should be reading vendor documentation carefully, because the difference between "encrypted in transit and at rest" and "the provider cannot decrypt this even under compulsion" is the entire security argument and both get described with the word "encrypted."

Portability is the related governance problem and it's mostly not technical. A synced passkey lives in an ecosystem, and moving it between ecosystems is a decision made by companies that are not you. Credential exchange formats have been under active work and are, as of this writing, at varying stages of implementation across platforms — I'd treat "my users can move their credentials between vendors" as something to verify against current reality rather than assume. Why Passkeys Won't Eliminate Passwords Any Time Soon walks the deployment consequences.

3. Recovery

The device is gone. The vault password is forgotten. Now what?

This is the hardest problem in the relocation and I'm not going to solve it here, because it's already covered properly: Passkey Account Recovery Is the Whole Problem and The Hardest Problem in Identity Is Recovery. What I want to add is the memory-specific observation.

Recovery is where memory gets reinstalled. Look at what a recovery flow actually asks for: something the user knows (security questions — a memorised secret with catastrophically low entropy and a public verifier, in the form of the internet), or a channel they control (email — protected by a memorised secret), or a code they were told to write down and did not. The relocated architecture has a memory dependency at exactly the point where the user is under stress, unrehearsed, and least able to satisfy it.

And the security arithmetic is the familiar min(): an account with a hardware-backed passkey and a knowledge-based recovery flow is a knowledge-based account. You have moved the memory dependency from the front door, where it was visible and instrumented, to the side entrance, where it is neither. That is an improvement — attacks now have to be targeted rather than bulk — but describing it as "we removed memorised secrets" is not accurate, and someone will eventually test the claim.

4. The enrolment boundary

Every relocation has a first step where the secret isn't relocated yet, and that step is the weakest link in the entire chain.

To put a credential into a device keystore, the system has to already know it's talking to the right person. In practice, that bootstrap runs on an emailed link, a temporary password, an onboarding code read out on a phone call, or an existing session. Which means: your phishing-resistant, hardware-backed, memory-free authentication has a floor set by a channel secret sent to an address you're trusting on first use.

The failure mode is worse than a stolen password, and this is the part that surprises people. An attacker who intercepts an enrolment link doesn't steal a credential; they create one, bound to their own hardware, indistinguishable from legitimate. It looks like a normal user with a normal device. There's no reset that dislodges it, because nothing about it looks wrong. Every architecture that relocates secrets needs to treat enrolment as a first-class security event: identity-proofed appropriately for what's being unlocked, short-lived, single-use, notified to every other registered device, and visible in the audit log as its own event type rather than buried in a generic account-update record.

The general principle, and it applies far beyond authentication: when you relocate trust, the residual risk collects at the boundaries — at the moment of enrolment, at the moment of recovery, and at the sync channel. Those three are the whole attack surface of a well-built relocated system, and they are all comparatively under-instrumented in most deployments, because attention follows the login path.

Memory never leaves. The question is what it's holding.

Now the reframing, which is the part I think is genuinely under-articulated.

Nobody actually ships a system with zero memorised secrets. Count them in the best modern setup you can build for a person:

• A device unlock secret. Biometrics are a convenience layer on top of it, not a replacement — every platform falls back to the PIN or passcode after a reboot, a failed match, or a timeout, which is one of the several reasons biometrics aren't secrets.
• A vault master password, or the platform account password that anchors credential sync.
• Something in the recovery path — a recovery phrase, a set of codes, an email account password.

Three, maybe two if the vault unlocks from the device. Not zero, and it will not be zero, because every chain of relocation has to terminate somewhere, and the only thing at the bottom that is always available, cannot be stolen physically, and survives losing every device you own is a human being who knows something.

So "eliminate memorised secrets" is the wrong goal, and stating it that way has led teams to build things that are worse — architectures that push the memory dependency into recovery flows and then don't design them.

The right questions are two: how many, and what does each one unlock?

And the second one has a specific technical form that reframes the whole discussion. Consider two memorised secrets:

• A six-digit device PIN. Roughly 20 bits, less in practice because people pick years and repeats. By password standards, indefensible.
• A twelve-character password with mixed classes. Nominally far stronger, and the thing every policy in the world asks for.

The PIN is dramatically safer, and it isn't close. The reason has nothing to do with entropy:

• Verification of the PIN happens inside hardware that enforces an attempt counter. Ten wrong guesses and the secure element wipes the key material or imposes escalating delays. The attacker's guess budget is not "a trillion per second"; it's ten, ever.
• Verification requires physical possession of the specific device. The attack cannot be run remotely or in parallel across a population. There is no such thing as PIN stuffing at scale.
• There is no verifier to steal. No server holds a hash of your device PIN. There is nothing to breach, nothing to exfiltrate, no offline phase.

Whereas the twelve-character password is verified by a server whose hash database may end up in an archive somewhere, checked offline, at billions of guesses per second, in parallel, against every user simultaneously. The 20-bit secret is protected by a rate limiter that physics enforces. The 78-bit secret is protected by an assumption about a database that has failed publicly, repeatedly, for thirty years.

Which gives the sharpest form of the thesis: memory was never the problem. Memory paired with an offline-attackable verifier is the problem. Everything the field learned the hard way — composition rules, rotation, entropy estimators, hashing work factors — is a series of attempts to make a human-chosen secret survive an offline attack, which is a fight the human component cannot win at any policy setting. Change the pairing and the requirement collapses. A short, memorable, rehearsed-daily secret guarding a hardware-throttled local key is good engineering. The same secret guarding a remote account is negligence. Same component. Different system around it.

That's why "the PIN is only six digits" is a category error when raised against passkeys, and why it keeps getting raised: the number is being compared against a threat model that no longer applies.

Here's the whole structure in one picture — what an attacker has to do in each case:

graph LR
    subgraph "Memory as the credential"
    A[Human memory] -->|types secret| B[Password]
    B -->|sent to server| C[(Verifier DB<br/>hash of the secret)]
    C -.->|breach: offline attack<br/>billions of guesses/sec<br/>whole population at once| X[Compromise]
    end

    subgraph "Memory as an unlock factor"
    D[Human memory] -->|PIN, local only| E[Secure element<br/>10-try counter]
    E -->|unlocks| F[Private key<br/>never leaves]
    F -->|signs challenge| G[(Verifier<br/>public key only)]
    G -.->|breach: nothing usable| Y[No compromise]
    end

Two systems, the same fallible component, opposite risk profiles. The difference is not how much the human remembered. It's whether anything downstream lets an attacker guess offline.

Apply that lens to the memorised secrets that remain, and they sort themselves:

The vault master password is the one worth staring at. It's the only remaining memorised secret in a well-designed personal stack that is genuinely subject to offline attack — an attacker with a copy of the vault file can grind it at whatever rate the KDF permits. It is also, if the user unlocks with biometrics day to day, the one with the worst rehearsal schedule. High strength requirement, low rehearsal frequency: exactly the combination memory is worst at.

Which leads to a recommendation that sounds like heresy and is, I think, straightforwardly correct: write it down and store the paper somewhere physically secure. Paper in a home safe has a threat model — burglary, household members, fire — that is entirely disjoint from the threat model of an internet-facing account, and for the overwhelming majority of people it is a far better store than a memory that will fail at the worst moment. NIST's own guidance has been moving in this direction for years: SP 800-63B dropped composition rules and routine rotation, told verifiers to check candidates against blocklists of known-compromised values, and explicitly stopped treating the memorised secret as something to be maximised through user effort. The document's own term for a password is "memorized secret," which reads, in retrospect, like the field naming its own bug.

The general rule underneath: a memorised secret that is rarely rehearsed should be treated as cold storage, not as memory. Physical media, offline, deliberately inconvenient to reach. The mistake is trying to hold a rarely-used high-value secret in a component whose retention curve you already know.

What to do on Monday

Six things, roughly in order of how much they return for the effort.

1. Count the memorised secrets in your architecture, per role. This is a design review question that almost nobody asks, and it takes an afternoon. Walk a representative employee's day and write down every distinct value a human is expected to retrieve from memory: laptop, SSO, the vault, the two applications that aren't federated, the VPN, the shared credential for the legacy tool, the recovery flow, the PIN for the badge system. If the count is over four, you have a design problem, and the resulting workarounds are your real security posture rather than the policy document. The number itself is the metric — track it, and treat reducing it as a security deliverable rather than a usability one.

2. For each one, ask whether an attacker can guess it offline. That single question sorts your memorised secrets into "fine" and "load-bearing" faster than any entropy calculation. A secret verified only by local hardware with an attempt counter needs to be memorable, not strong. A secret whose verifier could end up in an archive needs to be generated, long, and ideally not memorised at all. Most organisations apply the same policy to both categories, which means simultaneously over-constraining the first and under-protecting the second.

3. Federate the stragglers before you buy anything. If some of your applications still have their own login form, the highest-return memory intervention available to you is not a new authentication technology — it's finishing the SSO rollout you started. Each application you federate deletes a memorised secret for every user and a credential store for you. It's unglamorous, it's usually blocked on a vendor or an internal team rather than on technology, and it beats a passkey pilot on cost per unit of risk removed by a wide margin.

4. Deploy a password manager as infrastructure, not as advice. "We recommend users adopt a password manager" is not a control. Provisioned, paid for, integrated with your directory, deployed to the fleet, with the browser extension actually installed and a policy that permits paste into password fields — that's a control. And note what it does that no policy can: it makes uniqueness free, which is the only property that defends against credential stuffing at all, as Longer Beats Complex concludes rather uncomfortably. Everything else your password policy does is a defence against offline guessing; uniqueness is the defence against the attack that actually happens.

5. Instrument the three boundaries. Enrolment, recovery, and sync are where the residual risk went. Concretely: make credential enrolment its own audited event type, not a field on an account update. Make recovery slow, loud, notified to every registered device, and revocable during the window. Know what your credential sync provider can and cannot decrypt, in writing. If you can't answer "how many authenticators were enrolled on this account in the last 90 days, and by what path" from your logs, that's the gap.

6. Reclassify recovery secrets as cold storage. Recovery codes, break-glass credentials, and root-of-tenancy passwords should not be in anybody's head, and should not be in the same vault they exist to recover. Printed, sealed, split if the value justifies it, stored physically, with a documented retrieval procedure that gets tested — because an untested break-glass procedure is a procedure that does not work. This is the single most common gap I see in otherwise well-designed identity architectures: excellent daily-path engineering, and a recovery story that lives in one person's memory or one shared document.

The line worth keeping

The reason the "users are bad at passwords" framing survives is that it locates the defect in a component we can lecture rather than in one we'd have to redesign. It's cheaper to run an awareness module than to federate forty applications, and the awareness module produces a completion metric.

But we don't design this way anywhere else. When a component's datasheet says it cannot meet the requirement, we don't run a training programme for the component. We change the design so the requirement lands somewhere that can meet it — and then we spend our effort on the new interfaces that change created, because that's where the failures will be.

Human memory has a datasheet. Small durable capacity, decay without rehearsal, interference that rises with similarity, no rate limiting, no revocation, no rotation, no audit. Every one of those properties has been known for longer than the field has existed. We are forty years into building authentication systems that specify the component out of spec and then express surprise, in incident reports, when it performs as documented.

The move is to relocate the secret to something built to hold it, and to accept that the relocation ends at a small number of memorised items that you then design around honestly. Not zero. Two or three, each of them chosen with a clear answer to what it unlocks and whether anything downstream lets an attacker guess it a billion times a second.

Count the memorised secrets in your system. If the number is large, that's your finding — and it was never the users'.