By NHI Mgmt Group Editorial TeamPublished 2026-06-25Domain: Governance & RiskSource: Axiad

TL;DR: The new post-quantum executive order gives agencies 30 days to name a migration lead and begin cryptographic inventory work, while 2030 and 2031 deadlines sit further out, according to Axiad’s analysis of Executive Order 14409. The immediate governance issue is visibility: organisations cannot migrate what they have not mapped, especially when machine identities and AI agents inherit cryptographic credentials.


At a glance

What this is: This analysis argues that the immediate PQC deadline is inventory and accountability, not the later algorithm cutover dates.

Why it matters: It matters because identity, certificate, and workload owners must now treat cryptographic discovery as part of IAM and NHI governance, not a separate compliance project.

By the numbers:

👉 Read Axiad's analysis of the new PQC executive order and identity inventory deadlines


Context

Post-quantum cryptography migration is really an identity and inventory problem before it becomes an algorithm problem. The executive order creates near-term accountability for cryptographic assets, which forces teams to locate where certificates, keys, service accounts, machine identities, and inherited credentials actually live.

That matters because most organisations do not maintain a complete, continuously updated picture of cryptographic dependencies across cloud, on-premises, and third-party systems. When identity spans humans, workloads, and AI-enabled services, the migration lead has to govern the full trust fabric, not just a list of ciphers.


Key questions

Q: What breaks if organisations treat PQC migration as a late-stage crypto refresh?

A: The programme usually fails at discovery, ownership, and sequencing before it fails at algorithm replacement. If teams do not know where cryptographic trust lives, they cannot prioritise the systems that matter most or prove which dependencies will break during migration. PQC readiness starts as an identity and inventory discipline, not a cutover exercise.

Q: When should organisations prioritise cryptographic inventory over algorithm migration?

A: They should prioritise inventory first, because migration plans are only as good as the trust fabric they map. If certificates, keys, service accounts, and workload dependencies are not documented, teams will miss hidden exposure and create outages during replacement. Discovery is the prerequisite control, not a side task.

Q: What do security teams get wrong about machine identities in PQC planning?

A: They often treat machine identities as implementation details rather than governance objects. In reality, service accounts and workload credentials can inherit cryptographic trust across platforms, making them central to migration scope, ownership, and risk ranking. If those identities are excluded, the inventory will be incomplete and the migration plan will be misleading.

Q: Who is accountable when cryptographic inventory is incomplete at the start of PQC migration?

A: Accountability should sit with the designated migration lead, but the broader answer is that identity, infrastructure, and application owners all share responsibility for the trust map. PQC migration fails when no one owns dependency truth. Governance frameworks should make that ownership explicit before deadlines tighten.


Technical breakdown

Cryptographic bill of materials for identity estates

A cryptographic bill of materials, or CBOM, is the inventory layer that records which cryptographic primitives, certificates, keys, and trust dependencies exist in a system. For identity programmes, that means tracing where cryptography protects authentication, signing, federation, and workload trust, not just where TLS is deployed. The challenge is that cryptography is often embedded inside applications, APIs, CI/CD pipelines, cloud services, and third-party integrations, so the true dependency chain is wider than asset owners expect. Without that map, migration sequencing becomes guesswork.

Practical implication: build CBOMs alongside asset inventories so PQC planning starts from dependency truth, not tool output.

Why machine identities complicate PQC inventory

Machine identities such as service accounts, certificates, and tokens often inherit cryptographic trust from the systems that create them. That makes them harder to enumerate than human identities because they are spread across platforms and may be created automatically during deployment or integration. In PQC terms, the problem is not only where keys exist but which identities and workloads depend on them to authenticate, sign, or exchange data. If those dependencies are invisible, the migration plan will miss the highest-risk trust paths.

Practical implication: include machine identities and workload trust relationships in the first discovery pass, not after the human identity review.

PQC migration leads need continuous inventory, not a snapshot

A point-in-time inventory becomes stale as soon as new certificates are issued, services are deployed, or systems are integrated. That is especially true in environments with hybrid identity estates, where cryptography is distributed across cloud, on-premises, and SaaS services. PQC migration therefore needs an operational inventory process that tracks change, dependencies, and ownership continuously. The governance lesson is simple: the control is not the spreadsheet, the control is the repeatable discovery model that keeps the spreadsheet current.

Practical implication: treat cryptographic discovery as an ongoing control owned by the migration lead and tied to change management.


NHI Mgmt Group analysis

Inventory is the real cryptographic control plane: The executive order makes visibility the first governing action because migration cannot be sequenced without knowing what cryptography exists, where it sits, and who owns it. That is not just a technical scoping issue. It is a governance model that treats cryptographic discovery as the prerequisite for any PQC programme, and practitioners should recognise that the control plane starts with inventory discipline.

Machine identity expands the cryptographic blast radius: PQC planning is no longer confined to certificates used by known applications. Service accounts, workload identities, and AI-enabled services inherit cryptographic trust in ways that make ownership and replacement paths harder to trace. The implication is that identity programmes must map cryptographic dependency chains, not isolated assets, if they want to avoid hidden exposure.

Continuous discovery beats deadline-driven remediation: The order’s 30-day lead designation creates immediate accountability, but the deeper lesson is that static inventories fail in dynamic environments. Every new deployment, integration, or certificate issuance changes the quantum exposure profile. Practitioners should treat continuous discovery as the durable operating model for PQC readiness, not a one-off compliance task.

Post-quantum readiness is a lifecycle problem, not a cipher problem: The same governance weakness that leaves secrets scattered across environments also leaves cryptographic assets unmanaged through their lifecycle. NHI and IAM teams already know that ownership, rotation, and offboarding determine whether identity controls work in practice. The implication is that PQC migration will fail where lifecycle governance is fragmented, because unowned trust assets cannot be prioritised, replaced, or retired on schedule.

Identity attack surface and cryptographic risk now converge: PQC migration leads should expect their work to overlap with identity security, not sit beside it. Cryptographic exposure increasingly follows the same paths as NHI sprawl, delegated trust, and inherited access. Practitioners should therefore manage PQC as part of the identity attack surface programme, where visibility, accountability, and dependency mapping are already core disciplines.

From our research:

  • 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
  • 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
  • For a broader view of the breach patterns that make cryptographic inventory urgent, see 52 NHI Breaches Analysis.

What this signals

Cryptographic inventory will increasingly be judged as an identity governance capability, not a compliance checklist. Teams that already manage NHI lifecycle, access reviews, and secrets discovery have a head start because the same operating model applies to PQC readiness. The practical signal is that cryptographic ownership needs to be attached to identity and change processes, not left inside one-time audit work. See the Ultimate Guide to NHIs for the lifecycle framing that underpins this shift.

Identity programmes should expect PQC to surface hidden trust debt across machine estates. The highest-risk systems are often the least visible ones, especially where service accounts and inherited credentials sit outside formal secrets management. In our research, 96% of organisations store secrets outside secrets managers, which is a strong indicator that discovery gaps will slow migration work unless the programme is redesigned around continuous visibility.

Cryptographic risk, NHI risk, and workload identity risk are converging into one operating model. That means the teams responsible for certificates, service accounts, and federation will need to plan together rather than in separate workstreams. The same trust fabric that supports authentication today will determine how fast you can retire quantum-vulnerable algorithms tomorrow.


For practitioners

  • Stand up a named PQC migration owner Assign one accountable lead who reports into the CIO or equivalent security owner and owns cryptographic inventory prioritisation, dependency mapping, and remediation sequencing.
  • Inventory cryptography by dependency, not asset label Map which certificates, keys, algorithms, and trust paths support authentication, signing, federation, APIs, and workload identity so you can see what breaks before you replace anything.
  • Include machine identities in the first discovery wave Track service accounts, certificates, tokens, and AI-inherited credentials alongside human-facing systems because hidden non-human identities often carry the most fragile trust relationships.
  • Make discovery continuous through change control Tie cryptographic inventory updates to deployment, certificate issuance, and access lifecycle processes so the map stays current after each environment change.

Key takeaways

  • The executive order makes cryptographic inventory the immediate PQC deadline, because migration cannot begin until organisations know what trust assets exist and who owns them.
  • Machine identities and inherited credentials widen the cryptographic blast radius, which means PQC readiness is now an identity governance problem as much as a cryptography problem.
  • Continuous discovery, ownership, and dependency mapping are the controls that will determine whether PQC programmes stay on schedule or stall in scoping.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0ID.AM-1Cryptographic inventory depends on knowing assets and dependencies.
NIST Zero Trust (SP 800-207)PR.AC-1PQC migration changes how trust is established across identity and systems.
OWASP Non-Human Identity Top 10NHI-03Unmanaged secrets and inherited credentials complicate PQC discovery.

Treat cryptographic trust as a Zero Trust dependency that must be explicitly inventoried and verified.


Key terms

  • Cryptographic bill of materials: A cryptographic bill of materials is the inventory of algorithms, certificates, keys, and trust dependencies used by a system. It shows where cryptography is embedded, which identities rely on it, and what must change during migration. In PQC planning, it is the map that turns cryptographic risk into executable work.
  • Machine identity: A machine identity is a non-human identity used by software, workloads, services, or AI-enabled systems to authenticate and exchange trust. It may be represented by a certificate, token, API key, or service account. For PQC programmes, machine identities matter because they often inherit cryptographic dependencies that are hard to see.
  • Cryptographic dependency: A cryptographic dependency is any system, service, or identity relationship that depends on a key, certificate, signature algorithm, or encryption scheme to function. When the dependency is hidden, replacement work can break applications or leave exposure behind. Effective PQC governance treats dependencies as first-class inventory objects.
  • Continuous discovery: Continuous discovery is the ongoing process of finding and updating cryptographic or identity assets as environments change. It differs from a snapshot audit because it tracks new deployments, certificate issuance, and trust changes over time. For PQC readiness, it is the only way to keep inventory accurate enough to govern migration.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Axiad: The Real Deadline in the New PQC Executive Order Isn't 2030. It's 30 Days. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-25.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org