Executing PQC Migration: Every Domain Where Cryptography Lives Is in Scope

Introduction

The governance overview describes who leads the PQC program. The board governance article explains how directors oversee it. The cost estimation article covers how to fund it. This article covers how to actually do it.

In my 120,000 Tasks analysis, I wrote that the key message is not the task count. It is the density of interdependencies between those tasks: between vendors and internal teams, between infrastructure foundations and application waves, between regulatory timelines and engineering capacity, between legacy OT constraints and modern security requirements. Managing those interdependencies is what makes PQC migration qualitatively different from anything most organizations have attempted.

Most planning frameworks simplify PQC execution into two layers: “infrastructure” (centrally controlled) and “applications” (distributed to business units). That model survives about 30 seconds in a real enterprise. Walk the actual technology estate of any large organization and you find that cryptography is embedded in places the CISO has never managed, under the authority of people who have never heard of PQC, operating under change management disciplines that bear no resemblance to IT project delivery. The accountable executive who plans for two layers and discovers a dozen will spend the first year of the program rewriting plans that should have been right from the start.

The Governing Principle: If It Uses Cryptography, It Is in Scope

Before mapping specific domains, one principle should be understood and endorsed by the board and the C-suite: every system, device, service, and vendor relationship that uses public-key cryptography is within the scope of the PQC migration program. Not eventually. From the start.

This sounds obvious. In practice, it is the principle that encounters the most resistance, because it means the PQC program reaches into parts of the organization that have never been part of any cybersecurity initiative. The facilities team that manages building access control. The plant manager who runs a refinery. The regional office in Southeast Asia with its own IT team. The marketing department that procured an analytics SaaS platform three years ago without telling IT. All of these environments use cryptography. All of them are in scope.

The accountable executive needs C-level endorsement of this principle before the program can plan honestly, because without it, entire domains will be excluded from discovery, omitted from the wave plan, and invisible in the board-level KRIs until someone asks “what about the OT network?” in year three.

What You Control

The smallest and most straightforward part of the estate is the infrastructure that the CISO, CIO, or CTO directly operates: the CA hierarchy, HSMs, network encryption endpoints (TLS terminators, VPN gateways, load balancers), identity and access management platforms, and the shared cryptographic libraries that applications consume. This is the only part of the organization where the accountable executive can simply direct the work. No negotiation with business units, no vendor dependency for the core decision-making, no governance authority gap.

This domain is also the foundation that most other domains depend on. Applications across the organization cannot begin using PQC certificates until the CA hierarchy supports them. Systems cannot perform PQC key operations until the HSMs are upgraded. Every downstream migration in every other domain eventually traces a dependency back to this central infrastructure.

For a large enterprise, migrating this domain takes 12-24 months from discovery completion to operational readiness, with the binding constraints being HSM vendor lead times (6-18 months, as I covered in the vendor governance article) and FIPS 140-3 validation timelines (12-24 months per module). The architecture design, deployment, testing, and parallel operations overlap with each other and with early work in other domains. Getting this foundation started early and planned with downstream dependencies in mind is the single highest-impact sequencing decision in the program.

Enterprise applications (ERP, CRM, HR systems, financial reporting, email, collaboration) sit nearby in terms of control, but their migration dynamics are different. They are centrally managed, but they serve every business unit. A change to SAP or Oracle that breaks a business process affects the entire organization. Change windows require enterprise change advisory board approval. Regression testing cycles are long. Vendor upgrade paths (when SAP or Microsoft releases a PQC-compatible version) constrain timing. The central IT team has authority to execute, but the organizational impact of getting it wrong makes these among the most carefully managed migrations in the program.

What You Govern but Don’t Control

This is where organizational friction begins.

Line-of-business applications (trading platforms, claims processing, supply chain management, customer portals) are managed by LOB IT teams. Each business unit has its own application portfolio, its own release calendar, its own testing environments, its own vendor relationships, and its own priorities. The payments team is not going to defer a revenue-generating feature release to accommodate a PQC migration change window unless someone with authority tells them they must.

The central program can set standards (which PQC algorithms, which hybrid mode configuration, which shared libraries to use). It can set timelines (your applications must be in Wave 3, completing by month 42). It can provide shared services (the PQC library, the testing framework, the architecture patterns). But the actual hands-on migration work happens inside the business unit, performed by people who report to the business unit head, not to the accountable executive.

This is why I argued in the governance overview that LOB heads must be on the steering committee, and why BISOs or BCIOs should lead the migration pods within their business units. A steering committee that approves a wave plan without LOB representation will produce a plan that the LOBs do not consider binding. The steering committee’s authority to hold LOBs accountable for their migration commitments is the governance mechanism that makes distributed execution work. Without it, every LOB will quietly deprioritize PQC behind their own business deliverables, and the program will discover this one missed milestone at a time.

Cloud infrastructure adds another layer of complexity. Under the shared responsibility model, your cloud provider (AWS, Azure, GCP) owns the platform-level encryption and migrates it on their timeline, not yours. You own the application-layer configuration, the key management policies, and any customer-managed keys. Your cloud engineering team can update TLS configurations and key management policies quickly (this is infrastructure-as-code, deployed through CI/CD pipelines). But if the cloud provider’s managed load balancer does not yet support hybrid TLS, you cannot migrate those endpoints regardless of your own readiness. Your migration timeline in this domain is partly yours and partly the vendor’s.

Regional and geographic IT in multinationals introduces regulatory divergence and operational autonomy. The Asia-Pacific region may run different platforms than Europe. Different regulatory timelines apply (DORA in the EU, CNSA 2.0 for US defense supply chains, MAS in Singapore, ASD/ACSC in Australia). A regional CIO who operates with significant autonomy will not accept a migration plan designed at headquarters without local adaptation. The central PMO must work with regional IT leadership to build regionally appropriate plans that satisfy both the enterprise program standards and local regulatory requirements.

What You Can Only Negotiate

SaaS applications (Salesforce, Workday, ServiceNow, DocuSign, hundreds of others) and vendor-managed infrastructure (managed SOC, managed hosting, outsourced data centers) represent domains where you have zero control over the cryptographic implementation. You consume whatever the vendor provides. If DocuSign’s digital signature implementation uses quantum-vulnerable algorithms, you cannot fix that. You can ask DocuSign when they plan to migrate, you can add PQC requirements to the next contract renewal, and you can evaluate alternatives if they do not have a credible roadmap. But you cannot write a line of code or change a configuration.

The governance response for these domains is entirely through the vendor governance framework: tiering vendors by cryptographic exposure and migration dependency, tracking their readiness through KRIs, building contractual requirements into new and renewed agreements, and maintaining substitution contingency plans for Tier 1 vendors who fall behind. There is no migration “pod” for these domains. There is a vendor liaison function that manages the relationship and feeds readiness data into the program.

What You Probably Don’t Know About Yet

Shadow IT is the domain that makes CISOs uncomfortable because it reveals a gap in their existing governance before PQC even enters the picture. These are applications and cloud services procured by business units outside IT governance: a marketing team’s analytics platform, a research group’s collaboration tool, a regional office’s file-sharing service. The teams using them may not know these services use cryptography. The CISO may not know these services exist.

Discovery is the first time anyone maps these services. Once identified, each one becomes a governance decision: absorb it into the formal IT estate and include it in the migration plan, replace it with a managed alternative that the program can govern, or accept the residual risk with compensating controls (network segmentation, data classification restrictions). The volume of shadow IT varies enormously by organizational culture. Some enterprises I have worked with discovered 30-40 unmapped services during PQC discovery. Others discovered hundreds.

Shadow IT is not a PQC problem specifically. It is an existing governance gap that PQC discovery exposes. Organizations that address it during the PQC program get a secondary benefit: improved IT governance and asset visibility that has value independent of quantum risk. This is one of the benefit buckets I described in the CISO budget article.

What Nobody in IT Has Ever Managed

This is where most PQC programs discover that their scope was too narrow.

Corporate OT sits inside your own headquarters and office buildings: building management systems controlling HVAC, lighting automation, physical access control (badge readers, turnstiles, door controllers), elevator controls, fire suppression systems, CCTV and video surveillance networks. These systems are connected to the corporate network. They use cryptographic protocols for management, control, and authentication. And they are managed by facilities management, corporate security, or building operations teams who have no relationship with the CISO and no awareness of PQC.

Establishing even basic visibility over these systems requires a conversation that has probably never happened: the CISO (or the PMO) approaching the facilities director to explain that the badge reader system, the elevator controller, and the BMS all use cryptography that will eventually need to be migrated or protected with compensating controls. That conversation needs executive sponsorship. A program manager walking into the facilities office and announcing that the PQC program needs to audit the building systems will be politely shown the door. A message from the CEO or COO explaining that the PQC program has enterprise-wide scope and that all departments are expected to cooperate will produce a different reception.

This is one reason the C-level endorsement of the governing principle (“if it uses cryptography, it is in scope”) matters so much in practice. Without it, every non-IT domain will treat PQC as an IT problem that has nothing to do with them.

What Operates on a Different Timescale

Industrial OT (SCADA systems, PLCs, distributed control systems in manufacturing, energy, oil and gas, utilities, water treatment, transportation) is the domain where PQC migration encounters physics. Device lifecycles run 15-25 years. Firmware may not be updatable. Change management is governed by safety protocols that prohibit untested modifications to running systems. The plant manager has final authority over any change to the plant’s technology, and the plant manager’s primary concern is safety and uptime, not cryptographic algorithm currency.

Central IT cannot compel a plant manager to accept a PQC upgrade. The program must work through the operational governance structures that govern plant modifications: safety reviews, management-of-change procedures, scheduled maintenance windows and turnarounds. A refinery cannot shut down for a cryptographic migration during peak production season. A water treatment plant cannot risk a control system failure to test a new TLS configuration. The migration timeline for these systems is measured in years, not quarters, and many devices will never migrate. For those, the strategy is compensating controls: encryption gateways at the OT/IT boundary, network segmentation, and documented risk acceptance through the KRI cascade.

I covered the OT challenge in detail in the 120,000 Tasks article. The key principle here is simpler: OT and IoT must be treated as separate execution workstreams with their own timelines, their own execution teams (controls engineers and safety specialists, not software developers), and their own risk acceptance thresholds. Do not let OT constraints slow down the IT migration. And do not let IT migration timelines create unrealistic expectations for OT.

Remote and field operations (oil rigs, substations, pumping stations, remote manufacturing sites, retail store networks, cell towers) add a logistics dimension: each site has its own local IT and OT environment, the site manager has authority over what happens there, and central IT may need to physically send someone to the site to touch the equipment. A utility with 3,000 substations needs either a very large field deployment team or a very long timeline. Both cost money.

IoT devices (sensors, embedded controllers, fleet telematics, medical devices, smart meters) are the most constrained domain of all. Many have fixed-function cryptographic implementations that cannot be updated. A sensor with a hardwired RSA implementation and 64KB of flash cannot run ML-KEM. Replacement is the only migration path, and replacement at scale (hundreds of thousands of devices across distributed environments) is a multi-year procurement and logistics program that resembles fleet management more than software migration.

Bringing Everyone to the Table

The domain map above illustrates a coordination challenge that cannot be solved by the PMO alone. Facilities managers, plant operators, regional IT directors, and LOB heads need to understand why PQC affects them, what the program needs from them, and what timeline they are working against. This awareness and alignment effort should begin in the first quarter of the program, before migration planning for their domains begins.

Four practical approaches work.

An executive-level internal launch (not a PowerPoint presentation but a working session chaired by the CEO or COO) where the accountable executive presents the PQC program’s scope to all affected domain owners. The key message: this program touches every part of the organization, the board has mandated it, and we need your cooperation. The working session format allows domain owners to ask questions, raise concerns about their specific constraints, and begin building the relationship with the PMO that will become critical during execution. This session should produce a signed acknowledgment from each domain owner that their domain is in scope and that they will designate a point of contact for the program.

Domain-specific awareness briefings tailored to each audience. The facilities team does not need to understand lattice-based cryptography. They need to understand that their building systems use digital certificates, that those certificates will need to be replaced or protected over the next several years, and that the PQC program will work with them to plan and execute the changes within their operational constraints. The plant operations team needs a briefing that acknowledges their safety protocols and maintenance cycles and explains how the program will integrate with their existing change management process rather than overriding it.

A steering committee that includes non-IT domain representation. I emphasized in the governance overview that the steering committee needs LOB heads. For organizations with significant OT, facilities, or distributed field operations, the steering committee also needs someone who can speak for those domains: a VP of Operations, a Chief Operating Officer delegate, or a facilities director. A steering committee that governs only IT domains will produce a program that migrates IT and quietly ignores everything else.

An ongoing communication cadence that keeps domain owners informed without overwhelming them. A quarterly update to all domain owners (what the program has accomplished, what is coming next, what will be asked of their domain in the next quarter) maintains awareness and prevents the program from appearing as a series of surprise requests. Domain owners who are regularly briefed cooperate better than domain owners who hear from the program only when something is needed from them.

Interdependencies Across Domains

The tasks in a large enterprise PQC program form a dependency graph where sequencing determines whether the program delivers in five years or twelve.

Vertical dependencies run from the central infrastructure down to every other domain. Applications cannot use PQC certificates until the CA hierarchy supports them. But “infrastructure must go first” is an oversimplification. Not all central infrastructure capabilities need to complete before any other domain can start work. The CA hierarchy must be ready before applications request PQC certificates, but VPN gateway migration can run in parallel with application TLS work. HSM upgrades must complete before applications that perform direct key operations can migrate, but applications using a key management API through an abstraction layer can move once the API supports PQC. Mapping these vertical dependencies at a granular level during planning determines how much parallelization is possible. The default assumption (“finish all infrastructure, then start everything else”) leaves most teams idle for 12-24 months. The granular approach (“start each domain’s work as soon as its specific prerequisites are met”) can recover 6-12 months of parallelization.

Horizontal dependencies cross domain boundaries. A LOB trading application sends digitally signed messages to an enterprise risk management system. If the trading application migrates to PQC signatures before the risk system can verify them, the integration breaks. A cloud-hosted customer portal authenticates against an on-premises identity platform. Both must support the same hybrid mode during the transition. These pairwise cryptographic dependencies run into the thousands in a large enterprise, and they connect systems across different domains with different owners, different release cycles, and different migration timelines. The wave plan must sequence these connected systems together or ensure that both sides support hybrid compatibility during the transition period.

External dependencies are vendor delivery milestones: HSM firmware availability, CA PQC certificate support, cloud platform PQC releases, SaaS vendor updates. When a vendor is late, every internal task downstream of that vendor shifts. The PMO must model cascading delays in advance and maintain the substitution contingency plans from the vendor governance article.

The false parallelism trap is the instinct to run everything concurrently. Parallelization that ignores vertical dependencies produces work that has to be redone. Parallelization that ignores horizontal dependencies produces integration failures. Parallelization that exceeds organizational capacity (more concurrent work than the central engineering team can support with security reviews and testing) produces poor-quality migrations. The PMO’s job is to find the maximum safe parallelization. In the programs I have worked on, the binding constraints are the central engineering team’s capacity for security reviews and the availability of shared testing infrastructure. Three to five concurrent migration pods during peak is typical for a large enterprise.

The Program Office Across All Domains

The PMO’s role is the same regardless of how many domains the program spans: manage the dependency graph, track progress, surface blockers, and ensure consistency. Its organizational reach expands with the domain model.

A PMO designed for two layers (infrastructure and applications) needs coordination leads for IT. A PMO designed for the full domain map needs coordination coverage across IT, OT, facilities, regional IT, cloud, and vendor-managed services. Not every domain needs a dedicated coordinator. The PMO can cluster related domains: an IT coordination cluster covering central infrastructure, enterprise applications, and LOB applications; a cloud and SaaS cluster covering cloud configuration and vendor-managed services; an OT and field cluster covering corporate OT, industrial OT, remote sites, and IoT. For a large enterprise at peak migration: 6-10 PMO FTEs organized by domain cluster.

Execution units should be designed to match each domain’s operating model. Migration pods (a pod lead from the business unit, application developers, QA, and a shared security liaison) work well for software-centric domains where teams write code, run tests, and deploy changes. For industrial OT, the execution unit needs controls engineers, safety specialists, and vendor field engineers alongside cryptographic engineering support. These teams operate under plant safety protocols, not IT change management, and they execute during maintenance windows and planned shutdowns, not sprint cycles. For remote sites, the execution model is a deployment team that travels between locations with a standardized migration package. For IoT, the execution model resembles fleet management: bulk procurement of replacement devices, field deployment teams, and a multi-year replacement calendar. For SaaS and vendor-managed domains, there is no internal execution unit. The vendor liaison function manages the relationship and feeds readiness data into the program.

Wave Planning Across Domains

Waves must account for domains operating on fundamentally different timescales. IT domains can realistically complete migration in 3-5 years. OT and IoT domains may take 7-10 years or longer. The program plan must accommodate both timescales without the longer OT timeline being used as justification for delaying the shorter IT migration.

A practical wave structure for a large enterprise: Wave 0 (months 0-12) covers HNDL mitigation on the highest-sensitivity channels, central infrastructure planning and vendor procurement, and discovery across every domain. Wave 1 (months 12-24) migrates central infrastructure and cloud configurations where providers already support PQC, and begins OT assessment. Wave 2 (months 18-30) launches pilot application migration pods with willing business units. Wave 3 (months 24-42) scales to broad application migration across business units and regions. Wave 4 (months 36-60) tackles complex legacy applications, corporate OT where feasible, and initial industrial OT pilots during maintenance windows. Wave 5 (months 48-84) executes industrial OT at scale, remote site deployments, and IoT device replacement programs. Wave 6 (months 60-96) handles cleanup, hybrid mode decommissioning, and validation of the complete estate.

The extended timescale for later waves (Wave 5 spanning years, Wave 6 potentially reaching year 8) reflects the reality that industrial OT and IoT cannot be compressed to IT timescales. A program plan that shows all domains completing in five years is a plan that has not honestly accounted for the OT and IoT domains.

Four criteria determine which systems go in which wave: dependency readiness (are the infrastructure prerequisites for this system’s migration complete?), data sensitivity and HNDL exposure (how long must this data remain confidential?), complexity tier (crypto-abstracted systems migrate faster than legacy crypto-embedded systems), and domain capacity (does this domain’s team have the change windows and staffing to absorb migration work in this period?).

Shared Services

The central cryptographic engineering team provides five shared services consumed by execution units across all domains: a validated PQC library wrapping the NIST-approved algorithms with the organization’s configuration requirements; architecture patterns and migration templates tailored to each domain type (how to migrate a Java application is different from how to deploy an OT encryption gateway); a shared testing framework for interoperability, performance, and security validation; security review and sign-off through the security liaison model; and a continuously updated knowledge base that captures lessons from earlier waves so that later teams do not repeat the same mistakes.

The knowledge base deserves particular emphasis. The compound return on documenting early-wave experiences is enormous. Every failure pattern discovered in Wave 2, every vendor product that behaved unexpectedly, every application framework that required a non-obvious configuration change, becomes institutional knowledge that accelerates every subsequent wave. Wave 3 pods that have access to Wave 2’s lessons will execute faster, avoid known pitfalls, and ask better questions of the security liaison. Organizations that treat documentation as overhead rather than investment will pay for that choice in rework and repeated mistakes across dozens of teams.

Progress Reporting by Domain

Board KRIs and steering committee dashboards should report migration progress by domain cluster, not as a single aggregate number. “65% migrated” is misleading if IT domains are at 90% and OT domains are at 10%. The board needs visibility into where the program is succeeding and where it is structurally constrained so that it can make informed decisions about resource allocation, risk acceptance, and timeline adjustment.

At the steering committee level, the dashboard should show each domain cluster’s status: how many systems have been discovered, assessed, remediated, validated, and deployed in production PQC mode. At the board level, these decompose into the aggregate KRIs described in the board governance article, reported quarterly. When a domain cluster is persistently behind plan, the steering committee and board need to see it as a domain-specific problem with a domain-specific cause (vendor delay, OT safety constraints, regional IT capacity), not as a generic program shortfall.

Practical Starting Points

For programs entering execution planning, six actions set the foundation.

First, secure C-level endorsement of the governing principle: every domain where cryptography lives is in scope. Without this, non-IT domains will treat PQC as someone else’s problem.

Second, map every domain during discovery. Most discovery efforts focus on central IT. Expand explicitly to cloud, SaaS, shadow IT, corporate OT, industrial OT, remote sites, IoT, regional IT, and vendor-managed services. Each domain needs its own discovery approach: network scanning for IT, vendor questionnaires for SaaS, physical inspection for OT.

Third, hold the executive-level internal launch within the first quarter. Get every affected domain owner in the room, explain the scope, and secure their designated point of contact.

Fourth, map the dependency graph before building the wave plan. Three to six weeks of mapping vertical, horizontal, and external dependencies will save months of rework. This mapping is the single highest-value planning activity in the program.

Fifth, design execution units appropriate to each domain. Migration pods for software. OT teams for plant environments. Deployment teams for field sites. Vendor liaison for SaaS. One execution model does not fit all domains.

Sixth, plan wave timescales by domain, not by calendar. IT completes in 3-5 years. OT and IoT may take 7-10 years. The program plan must accommodate both without the longer timeline becoming an excuse to delay the shorter one.

The execution challenge in PQC migration is the simultaneous management of domains with different ownership, authority, speed, and constraints, all connected by a dependency graph that means a delay in one domain cascades into others. The PMO that plans for this complexity from the start will deliver. The PMO that discovers it mid-program will spend its time rewriting plans instead of migrating systems.

The PQC Migration Framework provides the full methodology across all eight phases. Quantum Ready covers execution as part of the complete readiness strategy.