Post-quantum cryptography is no longer a distant research topic for federal IT teams. OMB Memorandum M-26-15 turns it into a planning requirement, a procurement issue, and a future contractor-readiness test.

Zscaler's analysis of M-26-15 is useful because it translates the memo into concrete migration-plan components: named governance, a cryptographic inventory, risk-based prioritization, phased milestones, TLS 1.3 planning, crypto-agile architecture, vendor coordination, funding estimates, and transition-period risk management.

For small businesses and government contractors, the immediate takeaway is simple: agencies will need evidence from their vendors. If your systems, SaaS products, managed services, appliances, APIs, or support contracts touch federal environments, customers will eventually ask what cryptography you use, where it lives, whether it is replaceable, and how you will support PQC-ready standards.

What M-26-15 changes

The memo pushes agencies to move from awareness to execution. That starts with assigning accountability and producing a migration plan that is more than a policy statement. Agencies need to know which cryptographic algorithms, keys, certificates, libraries, protocols, appliances, and cloud services are in use across their environment.

Zscaler highlights the importance of a Cryptographic Bill of Materials, or CBOM. That concept matters because cryptography is buried everywhere: TLS termination points, VPNs, identity providers, software update mechanisms, APIs, databases, HSMs, embedded devices, SaaS integrations, CI/CD systems, and vendor-managed platforms.

Manual spreadsheets will not scale. A credible plan needs a method for discovering cryptographic use, keeping that inventory current, and tying it to business criticality and data sensitivity.

The contractor angle

This is where government contractors should pay attention. M-26-15 is aimed at federal agencies, but agencies rely on commercial software, cloud services, integrators, MSPs, MSSPs, device vendors, and subcontractors. Zscaler notes that vendor and supply-chain coordination are part of the required planning work.

That means PQC readiness is likely to show up in procurement language, security questionnaires, system authorization packages, and vendor risk reviews. Contractors may not need to be fully migrated tomorrow, but they should be able to explain:

  • Which products, systems, and services use public-key cryptography.
  • Where TLS, VPN, SSH, code-signing, S/MIME, certificate authorities, and key-management systems are used.
  • Whether the organization can replace cryptographic algorithms without rebuilding the entire architecture.
  • Which vendors and cloud providers must support the transition.
  • Which systems store data with long-term sensitivity that could be exposed by harvest-now-decrypt-later activity.

Why this matters now

The risk driving PQC migration is not only future decryption. Adversaries can collect encrypted traffic or stored ciphertext today and wait for cryptographically relevant quantum computers later. That makes long-lived sensitive data the priority: government records, legal data, health information, engineering data, identity data, contract data, and anything tied to national-security or critical-infrastructure missions.

The migration timeline also creates operational risk. Organizations will spend years in hybrid environments where some systems support modern algorithms and others do not. That transition period can create downgrade paths, broken interoperability, unsupported appliances, certificate chaos, and visibility gaps if it is not planned carefully.

Defensive takeaways

  • Start the cryptographic inventory. Identify certificates, protocols, algorithms, keys, libraries, appliances, and cloud services. Do not limit the inventory to internet-facing TLS.
  • Prioritize by data lifetime. Systems holding long-lived sensitive data should move earlier than low-impact systems with short-lived information.
  • Build crypto-agility into architecture. Make algorithm replacement a design requirement for identity, VPN, API, certificate, and key-management systems.
  • Track TLS 1.3 readiness. Legacy TLS stacks, inspection devices, load balancers, embedded systems, and old agents often become the migration blockers.
  • Update vendor questions. Ask suppliers how they inventory cryptography, support NIST PQC algorithms, manage certificates, and handle hybrid migration.
  • Connect PQC to procurement. New systems bought today should not become expensive blockers in 2028 or 2030.
  • Document ownership. Every cryptographic dependency needs an owner, replacement path, and business impact rating.

Bulwark Black assessment

The organizations that handle PQC well will not treat it as a single patch cycle. They will treat it as asset management, architecture, procurement, and incident-risk reduction rolled together.

For SMBs and government contractors, the practical move is to start with the inventory and vendor mapping. You do not need a perfect PQC program on day one. You do need enough visibility to answer customer questions, avoid buying systems that cannot migrate, and show that cryptographic risk is being managed deliberately.

This is also a compliance opportunity. Contractors that can explain their cryptographic dependencies, migration assumptions, and supplier requirements will look more mature than competitors waiting for boilerplate contract clauses to arrive.

Source: Zscaler — What OMB Memorandum M-26-15 Requires for Your Agency's PQC Migration Plan