The UK Department for Work and Pensions updated its Cryptographic Key Management Policy on August 7, 2026. The document is specific to DWP and its suppliers, but its operating model is broadly useful: maintain approved algorithm guidance, document where cryptographic solutions are applied, keep a key inventory, assign accountable owners, prepare compromise procedures, govern suppliers, train personnel, and retain audit readiness.
This is a timely reminder that cryptographic management is not synonymous with storing keys in an HSM. Technology can protect key material, but governance must still determine what exists, why it exists, who controls it, where it may be used, how it changes, and what happens when it is compromised or no longer needed.
A key inventory is connected operational state
The policy requires cryptographic keys to be recorded in an inventory and calls for documentation of locations where cryptographic solutions are applied. Those are related but different views. A key record without its systems and uses lacks impact context. A system record without its keys, certificates, algorithms, modules, and protocols cannot support lifecycle decisions.
A mature cryptographic inventory connects the material to its function and dependencies: owner, application, environment, algorithm, key length, certificate, module, storage location, data classification, creation date, rotation or expiry, backup state, supplier, and evidence source. Not every field applies to every object, but the relationships matter when policy changes or an incident occurs.
For example, revoking a certificate may be straightforward while replacing a root embedded in devices can require a multiyear program. Rotating a service key can affect availability if replication and failover are not understood. Destroying a key can be correct at end of life and disastrous if retention obligations or encrypted backups still depend on it. Inventory context turns a generic control into a safe action.
Accountability has to cross organizational boundaries
The DWP policy applies not only to employees but also to contractors, service providers, certificate authorities, designers, and suppliers handling key material or protected information. It calls for contract terms covering key ownership, breach notification, audit rights, and adherence to cryptographic policy.
That scope reflects how cryptography is actually delivered. Organizations consume certificates from external authorities, encryption from cloud services, signing from build systems, secrets from managed platforms, and embedded cryptography from commercial products. The operational owner and the technical custodian may be different entities.
Governance should make those boundaries explicit. Who authorizes use? Who generates and stores the key? Who can rotate or revoke it? Who receives incident alerts? Who supplies evidence? Who pays for a hardware or software replacement? A supplier statement that encryption is provided does not answer those questions.
Lifecycle controls must be testable
The policy covers secure distribution and storage, backup, revocation, destruction, compromise response, certificate lifetimes, isolation of root certificate authorities, training, review, and audit. These controls form a lifecycle. They should be represented as state and tested as procedures rather than left as prose.
Consider compromise readiness. A plan should identify the affected systems, dependent certificates or data, decision authority, replacement mechanism, notification path, recovery prerequisites, and proof that old material is no longer accepted. A contact list and a written policy are useful, but a rehearsed rotation or revocation is stronger evidence.
Likewise, “stored in an approved HSM” should resolve to the actual module, deployment, configuration, validation status, support lifecycle, access controls, and backups. The assurance applies to the implemented boundary—not automatically to every application that references a branded product.
Approved lists must be mapped to observed use
Maintaining an approved cryptographic algorithm list is necessary, but the control works only when actual use can be evaluated against it. Organizations need to identify disallowed algorithms, weak parameters, expired certificates, unsupported libraries, unapproved modules, and exceptions across environments.
That comparison must be repeatable because cryptographic state changes. Certificates renew, packages update, services move, suppliers revise configurations, and policies deprecate algorithms. Point-in-time spreadsheets lose value quickly unless they are connected to continuing discovery, ownership, action, and evidence.
Post-quantum migration increases the importance of this foundation. New algorithm policy will affect different functions on different schedules. A reliable system of record lets teams locate quantum-vulnerable dependencies, prioritize them using business and data context, and prove what was remediated without confusing lack of visibility with lack of exposure.
What organizations should do next
- Join key and system inventories. Connect keys and certificates to applications, modules, owners, uses, and protected information.
- Define lifecycle states. Track creation, activation, distribution, rotation, backup, revocation, expiry, destruction, and exceptions.
- Map supplier responsibility. Record custody, authorization, incident duties, evidence obligations, and change-notification terms.
- Test critical procedures. Exercise rotation, revocation, failover, recovery, and compromise response.
- Evaluate continuously. Compare observed cryptography with approved policy and retain evidence of decisions and remediation.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop is discovery, canonical inventory, evaluation, action, and proof. Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps.
Vista helps organizations reconcile cryptographic observations, evaluate them against policy, assign accountable actions, and retain evidence over time. It can support key-management and PQC governance, but it does not replace an HSM, generate PQC keys, or perform every migration. Vista is not a vulnerability scanner. Selected-asset Active Scan is not indiscriminate network scanning, and discovery gaps do not prove absence. Teams can review the evaluation paths on Try Vista.
Where uncertainty remains
The public policy refers to supporting DWP security standards and an approved algorithm list that are not fully reproduced on the page. Organizations outside DWP should not treat its requirements as their own legal mandate. They should use the policy as an operational reference, then map controls to their jurisdictions, assurance needs, architectures, and contracts. The enduring lesson is that key management works when inventory, accountability, lifecycle action, and proof remain connected.
Sources
- Cryptographic Key Management Policy, UK Department for Work and Pensions, updated August 7, 2026.
- RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, RFC Editor, November 2003.