Should organisations prioritise PQC readiness or device trust first?

Which should come first: PQC readiness or device trust?

They solve different problems, but the ordering should follow blast radius. pqc readiness protects long-lived cryptographic dependencies from future quantum breakage, while device trust protects the runtime environment you rely on today. If unmanaged devices or weak firmware trust can compromise access or signing, that operational risk usually deserves attention before deeper migration work.

Why the decision depends on where trust is actually enforced

PQC readiness is about mapping where your organisation depends on public-key cryptography, then making sure those dependencies can migrate without service disruption. That includes certificates, code signing, TLS, device enrollment, and any workflow that depends on durable cryptographic assurance. Post-Quantum Readiness for Identity and PKI is most useful when you need to inventory those dependencies and plan crypto-agile transitions.

Device trust, by contrast, is about whether the endpoints, IoT devices, and embedded systems you are already accepting into the environment can be identified, attested, and controlled with confidence. If devices can appear unmanaged, are difficult to monitor, or bypass signing checks, then the trust boundary is already weak. Device and IoT Identity Guide covers the controls that make that trust boundary explicit.

The practical distinction is that PQC readiness is often a migration programme, while device trust is a live control problem. You can sequence the work separately, but if device trust is poor, the resulting exposure can affect identity, update integrity, and software distribution regardless of how mature your PQC planning is. Machine Identity, PKI and Certificate Lifecycle Guide is relevant where certificates and signing are part of both trust and migration.

What changes when the device layer is weak

Weak device trust is an immediate exposure because it can let compromised hardware, rogue firmware, or unsigned software participate in trusted workflows. That means one failure can affect access control, patch distribution, telemetry integrity, and even code signing assumptions. Zero Trust Identity Guide helps frame those device checks as part of continuous verification rather than a one-time enrollment step.

PQC readiness does not remove those risks. A future-safe algorithm does not help if today’s device can still be impersonated, tampered with, or enrolled without strong proof of origin. The real question is which weakness has the broadest operational impact right now. If device identity, attestation, or software provenance is unreliable, that is usually the first constraint to fix because it influences every downstream trust decision.

If your environment already has strong device trust, then PQC readiness becomes the higher-priority strategic work, especially for long-lived certificates, firmware signing, and any asset expected to remain in service through the migration window. In that case the risk is less about immediate compromise and more about avoiding future lock-in, outage, or rushed replacement when current algorithms age out.

Practitioner Guidance

What to prioritise: Start with the trust domain that most directly affects current control failure. If devices are hard to attest, hard to inventory, or able to run untrusted code, fix that first because it widens the blast radius of every other control. If device trust is already mature, shift earlier to PQC dependency mapping and migration sequencing.

Decision rule: If a weakness can let an untrusted device, firmware, or signing process into production, treat it as an active security issue. If the main concern is long-term cryptographic obsolescence, treat PQC as a resilience and lifecycle programme, not an emergency replacement exercise.

What good looks like: You should be able to name the systems that depend on certificates, signing, and attestation, and also prove which device classes are trustworthy enough to carry those controls. When both are visible, you can decide whether the environment needs containment first or crypto-agility first.

Practitioner takeaway: Prioritise the trust problem that can currently break multiple controls at once, then use PQC readiness to protect the cryptographic layer from future failure rather than as a substitute for runtime assurance.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations prioritise device trust or collaboration hardening first in Microsoft 365?
• Should organisations prioritise Zero Trust or UEM first for device sprawl?
• Should organisations prioritise inventory or automation first for PQC readiness?