Managing Credential Storage Limits on Security Keys

A hardware security key holds a bounded number of discoverable credentials — frequently a few dozen — and when the storage is full, registration fails. This page covers what consumes a slot, how a preference rather than a requirement keeps the ceremony working, and what to tell a user whose key has run out. It sits under Discoverable vs Server-Side Credentials, which explains why residency matters in the first place.

Constraint Reference

Constraint Behaviour Consequence
Slot count fixed per model, typically a few dozen new discoverable credentials fail once exhausted
Freeing slots only through the vendor’s management tool you cannot free them remotely
Server-side credentials consume no storage unlimited in number on any authenticator
Platform authenticators storage managed by the operating system effectively unbounded in practice

Nothing your relying party does can reclaim a slot. A credential you revoke on your side remains on the device until its owner removes it.

What consumes a slot, and what does not Only discoverable credentials occupy authenticator storage; server-side credentials cost nothing on the device. Slots are finite, and only the user can free them discoverable credential occupies one slot, permanently, until deleted with a vendor tool server-side credential stores nothing on the device — the key is wrapped into the id platform authenticator storage managed by the operating system; effectively unbounded a deleted relying party slots are only freed by the user, never by you

Root Cause Analysis

1. Requiring residency unconditionally. The most common cause of a hard failure. A user with a well-used security key meets an error the moment your ceremony insists on a resident key, and neither the browser nor your page can explain what happened.

2. Enrolling more than one credential per authenticator. Two credentials on the same key for the same account consume two slots and provide no additional resilience — losing the key loses both.

3. Stale exclude lists blocking re-enrolment. A user who factory-resets a full key to reclaim space then finds they cannot re-enrol, because your exclude list still contains the credential that no longer exists on the device.

4. Reporting the failure as a generic error. The browser’s message is not actionable. Without your own explanation, the user’s reasonable conclusion is that security keys do not work with your product.

Preferring rather than requiring A preference lets the client fall back to a server-side credential when storage is exhausted. One word in the options decides whether a full key is fatal preference sent residentKey: preferred storage full no slot available client falls back server-side credential ceremony succeeds with a usable credential Requiring residency in the same situation ends the ceremony with an error the user cannot interpret or resolve on their own.

Step-by-Step Resolution

Step 1 — express residency as a preference

Ask for a resident key; do not require one. The client will fall back to a server-side credential on a full authenticator, and the user still ends up signed in.

Step 2 — record what you actually got

The response reports whether a resident key was created. Persist it, because it determines whether that credential can ever answer a usernameless ceremony.

Step 3 — keep exclude lists free of revoked rows

A revoked credential must leave the exclude list at the moment it stops being usable, so that a user who resets their key can enrol again.

Step 4 — detect the full-key case and explain it

When a ceremony fails on a roaming authenticator during registration, offer a specific explanation: the key may be full, and the vendor’s management tool can list and remove credentials. Link to it.

Step 5 — do not enrol twice on one device

Check the exclude list is doing its job. A second credential on the same authenticator is a wasted slot.

Reducing slot pressure Four measures that keep credential counts manageable without asking users to manage storage. Four measures, none of which require the user to understand slots prefer residency rather than requiring it do not enrol a second credential on the same authenticator keep exclude lists accurate so re-enrolment is possible after a reset tell the user plainly when their key is full, and how to clear it The fourth matters most: a full-key error with no explanation is the point at which people give up on hardware keys.

Verification and Testing

A virtual authenticator configured without resident-key support is the cheapest way to exercise the fallback path: assert that a ceremony expressing a preference still completes, and that your code records a non-resident credential rather than assuming residency.

Test the exclude-list hygiene explicitly. Revoke a credential, then assert that a subsequent registration options payload no longer contains it. This is the check that keeps a factory reset from becoming a permanent lockout.

If you can, test against a real key with storage deliberately filled. It is the only way to see the actual error your users will meet, and the message differs enough between browsers that guessing at it produces unhelpful help content.

Pitfalls

1. Assuming residency succeeded. Read the reported property rather than the preference you sent.

2. Treating a full key as a bug in your product. It is a device constraint, and the user can resolve it — but only if told how.

3. Offering “try again” as the remedy. The state is durable; a retry fails identically.

Frequently Asked Questions

How many credentials does a security key actually hold?

It varies by model and by firmware generation, and the number is published by the vendor rather than discoverable at runtime. A few dozen is typical for current hardware; older keys hold considerably fewer. Because you cannot query it, the only robust design is one that degrades when the limit is reached.

Can I check remaining capacity before enrolling?

No. There is no API that reports it, and there is deliberately no way for a page to interrogate an authenticator’s storage. The failure is the signal, which is why handling it gracefully matters more than predicting it.

Does revoking a credential on my side free a slot?

No. The credential remains on the device until its owner removes it with the vendor’s tool. This asymmetry surprises users, and it is worth a sentence in your help content.

Are server-side credentials a reasonable answer for security keys?

Yes, for a key kept as a backup. The account is already identified when a backup credential is used, so discovery adds nothing, and a server-side credential consumes no storage. Reserve the slots for the surfaces where usernameless sign-in genuinely matters.

Do platform authenticators have the same limit?

Not in any practical sense. Credentials are stored by the operating system, frequently synced to the user’s account, and the effective ceiling is far beyond what any individual will reach. Always prefer a resident key there.

What should the error message say?

Something concrete: that the security key appears to be full, that credentials can be reviewed and removed with the vendor’s management application, and that the user can alternatively sign in on this device with a passkey. Naming the cause is what turns a dead end into a next step.

Does this affect enterprise deployments differently?

It affects them more, because an employee using one key across many internal applications accumulates credentials faster than a consumer does. An organisation issuing keys should plan for slot exhaustion as a lifecycle event rather than as an exception.

How should an organisation plan for slot exhaustion?

As a lifecycle event with an owner, not as a support surprise. An employee using one key across many internal applications accumulates credentials steadily, and the moment the key fills is the moment they cannot enrol in a newly launched system. The practical measures are to standardise on preferring rather than requiring residency across internal relying parties, to keep an inventory of which applications enrol resident keys, and to give the service desk a documented procedure for reviewing and clearing a key with the vendor tool. Issuing a second key per employee is also reasonable, and has the additional benefit of covering the lost-key case that would otherwise route through account recovery.

Treating it this way also makes the cost visible at procurement time, when the choice of model and its slot count is still an open decision rather than a constraint discovered two years later.

Can a user tell how full their key is?

Only through the vendor’s management application, which lists the credentials stored on the device and allows individual removal. That tool is the answer to almost every question in this area, and linking to it from your error handling is the single most useful thing a relying party can do — because the alternative, from the user’s point of view, is a device that has silently stopped working with no visible cause and no obvious remedy.

Related