When should organisations begin PQC planning if regulations are still mostly soft asks?

Organisations should begin now if they manage long-lived data, external trust relationships, or PKI-dependent services. PQC migration is slow because discovery, impact analysis, vendor coordination, and implementation all take time. Waiting for final mandates increases operational risk and compresses remediation windows. Q4 2025 is effectively the last practical starting point for many teams.

Why This Matters for Security Teams

PQC planning is not a cryptography-only exercise. It is a dependency and exposure review that reaches PKI, TLS termination, code signing, partner connections, archival data, and any system that must remain trustworthy after classical public-key algorithms age out. The practical risk is not just future decryption. It is the time needed to discover where cryptography is embedded, assess vendor readiness, and sequence replacements without breaking production. That is why the NIST Cybersecurity Framework 2.0 matters here: it frames governance, inventory, and risk treatment before a control becomes urgent.

For NHI-heavy environments, this is especially relevant because service identities, certificates, and machine-to-machine trust often outlive the teams that created them. NHIMG’s research shows how often organisations miss the basics of lifecycle control and secret hygiene, which makes any future cryptographic transition harder than it should be. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives and Top 10 NHI Issues both point to the same operational reality: weak inventory and weak ownership slow every security migration.

In practice, many security teams encounter PQC scope creep only after a renewal, outage, or vendor notice has already compressed the timeline.

How It Works in Practice

The right way to start is to treat PQC as a staged readiness program. First, build a cryptographic inventory that identifies where RSA, ECC, ECDSA, TLS, PKI, signing workflows, and certificate-based service authentication are used. Then map each dependency by data sensitivity, expected lifespan, and replacement complexity. Current guidance suggests prioritising anything that protects long-lived confidentiality, such as regulated archives, source code, firmware signing, and external trust chains.

Next, separate “must be secure now” from “must survive later.” Some systems can wait for standards to settle; others cannot. A practical programme usually includes these steps:

• Discover all crypto dependencies across applications, infrastructure, third parties, and NHIs.
• Classify which workloads need hybrid or dual-stack support during transition.
• Engage vendors early on firmware, HSM, cloud services, and certificate tooling.
• Test interoperability in non-production before setting any migration deadline.
• Track certificate and key lifecycles alongside NHI lifecycle management.

For machine identities, the issue is often not the algorithm alone but the surrounding trust fabric. Certificate rotation, automated issuance, and offboarding discipline all affect how painful pqc migration becomes. That is why NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful operational companion, because it links identity lifecycle control to migration readiness. Organisations should also align the programme to internal governance using NIST Cybersecurity Framework 2.0 categories for asset management, protection, and recovery.

These controls tend to break down when cryptography is embedded in third-party appliances or legacy OT systems because replacement windows are slow and vendor support is uneven.

Common Variations and Edge Cases

Tighter PQC planning often increases near-term overhead, requiring organisations to balance transition cost against the risk of delayed discovery. That tradeoff is most visible in environments with long-lived certificates, regulated retention, or externally exposed trust anchors. In those cases, “wait for the mandate” is usually the wrong posture because the migration work is already real, even if the requirement is not.

There is no universal standard for this yet. Best practice is evolving, but a few edge cases are clear. Internet-facing services, software supply chain signing, and partner integrations should move first because they are hardest to coordinate under pressure. Internal-only systems may follow later, provided the organisation has a complete inventory and a credible rotation path. Purely ephemeral data flows may not need immediate cryptographic redesign, but any system that protects data with multi-year sensitivity should be treated as a priority.

Another common mistake is assuming that “crypto agility” is enough by itself. It helps, but agility without ownership, vendor accountability, and test coverage just delays the same problem. For that reason, organisations should not wait for final regulation language before starting discovery and planning. In identity-heavy estates, especially those with weak secrets hygiene, the safer path is to begin now and use the transition to improve lifecycle governance at the same time.

Related resources from NHI Mgmt Group

• When should organisations begin migration planning for SAP S/4HANA?
• Why do cloud password platforms still create concern for organisations with strict access governance?
• How should organisations handle emergency lockout when a user may still retain access across multiple connected systems?
• How do organisations operationalise NHI ownership at scale?