How should security teams prioritise cryptography migration across devices?

How to prioritise cryptography migration across a device fleet

Security teams should treat migration as a staged risk-reduction exercise, not a bulk replacement project. Devices that expose sensitive data, depend on older cryptographic primitives, or are likely to remain in service for years deserve the earliest attention, because delay increases both exposure and the cost of later remediation.

The practical question is not which device is easiest to move first, but which device creates the greatest residual risk if it stays on legacy cryptography. That usually means building a ranking that combines visibility, business criticality, dependency on the protected channel, and how hard the device will be to reach again once deployed.

What should drive the migration order?

Start with inventory quality. If teams cannot see where cryptography is used, they cannot assess which devices are pinned to obsolete algorithms, weak key sizes, or brittle certificate handling. A complete picture should include endpoints, embedded devices, shared platforms, and any system that authenticates other systems or stores long-lived secrets.

From there, rank devices by the value and sensitivity of the data they protect. A device that secures regulated records, production credentials, or privileged administrative access should move ahead of a low-impact endpoint, even if both use the same outdated protocol. The migration priority should track blast radius, not device count.

Longevity also matters. Devices with long replacement cycles, poor patchability, or hardcoded crypto dependencies should rise on the list because postponing migration extends the period in which the old design remains exposed. Where a device is costly to touch later, the right decision is often to migrate sooner and bundle the change with other lifecycle work. For device identity and trust dependencies, see the Device and IoT Identity Guide.

Which devices usually come first?

The highest priority devices are typically those that anchor high-value authentication paths, protect long-lived secrets, or mediate access to sensitive systems. If compromise of the cryptographic layer would let an attacker impersonate a trusted device, intercept credentials, or persist inside a critical workflow, that device belongs near the front of the queue.

Shared workstations, medical or industrial devices, and embedded systems can also deserve early migration when they are difficult to monitor or cannot tolerate extended dual-stack periods. In those environments, the main issue is often not just algorithm strength, but whether the device can safely operate during transition without breaking interoperability or trust chains. The same logic applies when device certificates and onboarding flows are central to trust, as discussed in the Device and IoT Identity Guide.

Teams should also treat secret-heavy devices as urgent. When a device stores private keys, API keys, tokens, or other identity material with a long lifetime, migration delay can preserve an unnecessarily large attack window. In practice, that makes secret rotation, certificate replacement, and cryptographic inventory part of the same prioritisation decision. Cases where old secrets are embedded in device software can be especially sensitive, as shown by the Rabbit R1 hard-coded API keys 2024 example.

How should teams sequence the work in practice?

A workable sequence is to group devices into migration waves, beginning with the most exposed and most critical assets, then moving outward to lower-risk populations. Each wave should be selected so that the team can verify success, monitor for interoperability issues, and roll back safely if a specific device class fails under the new cryptographic profile.

It helps to separate devices that can be updated centrally from those that require field replacement or vendor coordination. The former can often move earlier because the operational blast radius is easier to control. The latter need longer lead time, so their migration plan should start first even if the actual cutover happens later.

Where devices depend on third-party firmware, vendor certificates, or externally managed key material, prioritise early engagement with suppliers. Cryptography migration frequently fails at the integration boundary, not at the algorithm choice itself. That is why teams should verify support for the new cryptographic standard before they commit the device to a migration wave.

Risk and Threat Considerations

Legacy cryptography creates a compound risk: weak protection can persist silently for years, and the affected device often sits close to valuable data or privileged access. The longer the device stays in place, the more likely it is that attackers will target the outdated trust path rather than the device itself.

Failure mechanism: Migration is delayed on devices that are hard to inventory, hard to patch, or embedded in critical workflows, so obsolete algorithms, weak keys, or long-lived certificates remain active after the rest of the environment has moved on.

Impact: That delay can enable interception, impersonation, credential theft, or unauthorized access through a device that remains trusted by downstream systems. It also raises the cost of emergency replacement if the cryptographic weakness is later exposed.

Practitioner Guidance

What to prioritise: Put the oldest crypto, the longest-lived devices, and anything protecting high-value authentication or long-lived secrets into the first migration waves. If a device is both hard to replace and difficult to monitor, treat that as a priority signal rather than a reason to defer.

What to verify: Confirm where each device uses cryptography in the trust chain, not just whether it uses encryption. The key questions are whether the device authenticates other systems, whether it carries sensitive data, and whether it can be updated without breaking dependent services or certificate validation.

Practitioner takeaway: The safest migration order is usually the one that reduces residual trust first, not the one that is simplest to execute.

Related resources from NHI Mgmt Group

• How should teams secure non-human identities across cloud and SaaS?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams prioritise identity and access findings across many tools?
• How should security teams prioritise data security investment across IAM and governance programmes?