Should organisations keep more identity data in central repositories or move toward device-held credentials?

Central repositories vs device-held credentials: what actually changes

The real trade-off is concentration versus operational control. Central repositories make inventory, rotation, and recovery easier, but they also create a single place where compromise can expose many proofs at once. Device-held credentials reduce that blast radius, but they shift trust to endpoint integrity, secure enrollment, and revocation discipline.

Device-held models work best when the organisation can verify the device and the credential without having to retain a broad archive of reusable proofing artefacts. That is why many teams are moving from “store everything centrally” to centralise less and use secretless patterns where possible, especially for credentials that only need to prove possession, not be replayed forever.

Central repositories still make sense when the organisation needs strong governance over issuance, recovery, auditability, or cross-device portability. They are often the better fit for high-friction lifecycle events such as reproofing, emergency access recovery, and mass revocation, provided the store is tightly segmented and not treated as a universal cache of sensitive identity material.

What a safer target state looks like

The strongest pattern is usually hybrid: keep only the minimum durable identity data centrally, and push short-lived or device-bound credentials to the place where they are actually used. That reduces the amount of reusable material sitting in one repository while preserving enough central control to manage policy, trust anchors, and recovery.

Where organisations over-store data, the problem is rarely just “too much data” but “too much reusable data.” A central repository full of long-lived secrets, tokens, or high-value proofing artefacts can turn one compromise into a broad authentication event. By contrast, device-held credentials can narrow the attacker’s options if the device is strongly protected and the credential cannot be replayed elsewhere.

For many environments, the deciding factor is not whether central storage is technically possible, but whether the business can tolerate the recovery and breach consequences if that store is exposed. The more sensitive the artefact, the stronger the case for moving to reduce secret sprawl and limit credential concentration.

How to choose the model without creating a new weak point

The right answer depends on what you are trying to protect: proofing evidence, authentication material, lifecycle records, or the ability to recover access after loss. If the data is mainly needed for governance and audit, centralisation may be justified. If the data is mainly needed at runtime to prove possession or local trust, device-held or device-bound designs usually create a smaller breach surface.

A useful rule is to ask whether the central store is being used as a system of record or as a convenience layer for operational reuse. If it is the latter, it is often carrying more risk than value. If the organisation cannot explain why each retained artefact must remain centrally recoverable, it is probably time to remove, shorten, or partition that retention.

The same logic applies to lifecycle handling. Credentials that are harder to move centrally must be easier to rotate, revoke, and re-enrol at the edge. Teams that adopt device-held credentials without improving revocation and inventory usually trade one concentration problem for a visibility problem.

Risk and Threat Considerations

Large central identity stores create attractive breach targets because one compromise can expose many authenticators, tokens, or proofing records at once. The attacker value is not just theft, but reuse: once a central store contains reusable material, recovery and lateral abuse become much easier than if the credential lived only on a protected device.

Failure mechanism: A central repository becomes a high-concentration trust anchor, and a compromise, backup leak, insider misuse, or overly broad admin path can expose many credentials or proofing artefacts in one event. Attackers then exploit the reuse potential, not merely the data itself.

Impact: The result can be mass account takeover, faster persistence, wider blast radius, and more difficult recovery, especially where revoked material cannot be cleanly invalidated everywhere it has been copied.

Practitioner Guidance

What to verify: Confirm whether each retained identity artefact is truly needed centrally, or whether the organisation is storing it mainly because the process is old, not because the control model requires it. If you cannot defend the retention purpose, treat it as removable concentration risk.

Decision rule: If the credential can be device-bound, short-lived, and revoked quickly without breaking governance, prefer the smaller central footprint. If the organisation must preserve long-term recovery or legal traceability, keep the minimum centrally and isolate it from the runtime path.

What practitioners underestimate: Device-held credentials do not eliminate risk, they move it. The control question becomes whether endpoint trust, device recovery, and revocation are strong enough to replace the safety that a central store seemed to provide.

Practitioner takeaway: Avoid designing around convenience alone; keep central repositories small, purpose-limited, and recoverable, and push runtime credentials toward short-lived device-held forms wherever the trust model can support it.

Related resources from NHI Mgmt Group

• How do organisations reduce identity data exposure when using verifiable credentials?
• When should organisations move from static credentials to short-lived machine identity?
• Why should organisations move pipeline credentials to a central secrets manager?
• How should organisations decide whether to keep a central vault or move to a new model?