What breaks when organisations track PQC readiness as a static spreadsheet instead of an active workflow?

Static spreadsheets create false confidence and poor coordination. Teams lose sight of which assets are ready, which are blocked, and which need code changes or vendor releases. That leads to duplicated effort, missed deadlines, and delayed compliance. A workflow based approach keeps status current, shows dependencies, and gives security, PKI, and application teams one shared execution model.

Why This Matters for Security Teams

pqc readiness is not a document-management problem. It is a change-management problem across cryptography, application code, certificates, vendor dependencies, and infrastructure timelines. A spreadsheet can list assets, but it cannot enforce ownership, dependency order, or proof of completion. That matters because migration work usually spans PKI, application owners, platform teams, and procurement, and the real risk is not missing a line item. It is assuming an item is “on track” when it is blocked downstream.

NHI Mgmt Group’s research shows only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any readiness programme that depends on manual status tracking rather than live operational data. When cryptographic inventory is stale, teams tend to discover blockers only after a release window closes or a compliance review starts. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that security control implementation has to be traceable and maintained, not merely recorded.

In practice, many security teams encounter missed crypto dependencies only after a certificate renewal, application freeze, or vendor update has already failed.

How It Works in Practice

An active PQC readiness workflow turns migration into a governed process with states, owners, dependencies, and evidence. Instead of asking “Is this system ready?”, teams track “What exact step is blocked, who owns the next action, and what must change before approval?” That usually means integrating asset inventory, certificate discovery, application dependency mapping, and ticketing into one execution model.

At a minimum, the workflow should show:

• Which assets use RSA, ECC, or hybrid patterns and where they are exposed.
• Which systems need code changes, library upgrades, HSM updates, or vendor releases.
• Which certificates, trust chains, and key lifecycles are tied to release windows.
• Which exceptions are temporary and which require formal risk acceptance.

This is where a static spreadsheet fails. It cannot alert on a blocked vendor, cannot auto-reconcile a new certificate inventory, and cannot show whether a change request has moved from analysis to remediation to validation. A workflow can, especially when it is connected to the systems already used by PKI and platform teams. NHI Mgmt Group’s analysis of the GitHub Action tj-actions Supply Chain Attack shows how quickly hidden dependencies and stale trust assumptions can turn into operational exposure. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it maps well to evidence collection, change tracking, and accountability across remediation work.

These controls tend to break down in environments with fragmented ownership and outsourced application stacks because status updates stop matching real technical progress.

Common Variations and Edge Cases

Tighter PQC tracking often increases coordination overhead, requiring organisations to balance governance rigor against delivery speed. That tradeoff is real: if every dependency must be reviewed manually, the programme slows down; if teams are allowed to self-attest without evidence, the spreadsheet becomes theatre.

Best practice is evolving, but current guidance suggests treating readiness as a living workflow with exception handling rather than a one-time inventory. The right model depends on the environment:

• For large enterprises, multiple workstreams often need a shared backlog with dependency status rather than a single master sheet.
• For regulated sectors, evidence retention matters as much as migration progress because auditors will ask how decisions were made.
• For vendor-heavy estates, readiness often hinges on supplier commitments, so procurement and legal need the same workflow visibility as security.

There is no universal standard for PQC readiness tooling yet, but the operational principle is consistent: if the status cannot update when code, certificates, or vendor roadmaps change, it is not readiness tracking. It is a snapshot. NHI Mgmt Group’s broader guidance on identity lifecycle management in Ultimate Guide to NHIs is relevant here because the same visibility gap that affects non-human identities also undermines cryptographic transition planning.

In mixed environments, this approach gets harder when legacy systems cannot emit reliable dependency data and teams are forced to reconcile reality by hand.

Related resources from NHI Mgmt Group

• What breaks when organisations treat cryptography inventory as enough for PQC readiness?
• What breaks when organisations rely on a vendor risk score instead of reviewing active access?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?