How Arizona Can Execute PQC Migration at Scale | Sonoran Desert Security (SDSUG)

Arizona’s statewide blueprint for Post‑Quantum Security, a comprehensive, governance‑driven roadmap for deploying hybrid cryptography, enforcing vendor compliance, and transitioning Arizona to PQC‑only infrastructure across all sectors.

A Statewide Governance, Modernization, and Implementation Framework — 2026 Edition

Sonoran Desert Security (SDSUG) Research — Governance, Policy & Institutional Resilience

Post‑Quantum Cryptography (PQC) Modernization Series — Report No. 5 (2026)

Author: Hunter Storm (https://hunterstorm.com)

Version 1.0 — Published April 2026

About This Report

This report is published by Sonoran Desert Security (SDSUG) as part of its formal research publication series. It supports cybersecurity awareness, resilience, and informed decision‑making across Arizona, reflecting SDSUG’s role as a trusted institutional resource for clear, accessible guidance. The analysis is openly accessible for reading, learning, and citation by practitioners, policymakers, and community members, and is intended for full search engine indexing. All content on this page is non‑sensitive.

All materials remain the sole intellectual property of the author and may not be presented, republished, or redistributed as original work. Proper attribution is required under the Citation & Usage Policy.

By Hunter Storm

Post-Quantum Cryptography (PQC) Modernization Series — 2025–2026

Arizona’s transition to post‑quantum cryptography requires clear governance, statutory alignment, and sector‑ready implementation guidance. As part of the Sonoran Desert Security (SDSUG) Governance, Policy & Institutional Resilience domain, the Post-Quantum Cryptography (PQC) Modernization Series (2025–2026) provides a structured, practitioner‑driven framework for interpreting federal mandates, integrating statewide requirements, and preparing Arizona’s public‑ and private‑sector institutions for cryptographic modernization at scale. These reports translate national expectations into actionable state‑level pathways, ensuring that Arizona’s agencies, critical‑infrastructure operators, and governance bodies can move decisively as PQC standards evolve.

Purpose

The purpose of this report is to provide Arizona with a complete, actionable, statewide blueprint for executing post‑quantum cryptography (PQC) migration at scale. It establishes the governance structures, technical requirements, sector‑specific pathways, and vendor compliance mechanisms necessary to protect Arizona’s public‑sector systems, critical infrastructure, and citizen data from quantum‑enabled threats.

This report translates national PQC mandates into a state‑level operational plan, offering a unified framework that agencies, vendors, and cross‑sector partners can adopt without ambiguity. It defines the minimum standards for hybrid deployment, the transition to PQC‑only infrastructure, and the statewide coordination required to ensure interoperability, continuity of operations, and long‑term cryptographic resilience.

Abstract

Arizona faces an urgent and complex modernization challenge: transitioning statewide systems from classical cryptography to quantum‑resistant infrastructure before quantum‑enabled adversaries can exploit existing vulnerabilities. This report provides a comprehensive, end‑to‑end roadmap for how Arizona can execute PQC migration at scale, aligned with HB2809, the National PQC Modernization Mandate, and NIST’s PQC standardization track.

The report outlines the governance architecture required to coordinate agencies, vendors, and critical infrastructure partners; defines the technical and operational steps for deploying hybrid and PQC‑only cryptography; and establishes statewide procurement, contracting, and compliance standards. It includes sector‑specific modernization pathways, a phased transition timeline through 2035, and a cross‑sector map of readiness and risk.

By integrating policy, engineering, procurement, and operational guidance into a single statewide blueprint, this report enables Arizona to modernize securely, consistently, and efficiently—positioning the state as a national leader in quantum‑resilient cybersecurity.

Executive Summary

Arizona’s transition to post‑quantum cryptography (PQC) is no longer a theoretical modernization exercise. It is a statutory requirement, a statewide operational necessity, and a foundational component of Arizona’s long‑term digital sovereignty. HB2809 (2025–2026) mandates the adoption of NIST‑approved PQC algorithms, the execution of a full cryptographic asset inventory, and the prioritization of U.S.‑based vendors capable of delivering quantum‑resistant solutions.

This report provides Arizona with a comprehensive, scalable, and governance‑aligned roadmap for executing PQC migration across state agencies, critical infrastructure, education, public safety, and vendor ecosystems. It is designed to function as the statewide reference model for PQC modernization, aligning Arizona’s statutory requirements with the national PQC mandate, NIST’s FIPS 203/204/205 standards, and global best practices.

The report is structured to support executive leadership, technical practitioners, procurement officers, legislative analysts, and sector‑specific operators. It provides a phased migration model, a statewide governance architecture, a cryptographic census methodology, a supply‑chain sovereignty framework, and sector‑specific implementation guidance.

Arizona’s challenge is not simply to adopt PQC algorithms. It is to execute a coordinated, multi‑year, cross‑sector modernization effort that protects the state’s most sensitive data, ensures continuity of operations, and positions Arizona as a national leader in quantum‑era cybersecurity.

This report outlines how to do exactly that.

Key Findings

1. Arizona’s PQC mandate is both statutory and operational

HB2809 requires:

adoption of NIST‑approved PQC algorithms
statewide cryptographic asset inventories
U.S.‑based vendor sourcing
CMMC‑aligned cybersecurity posture
validation of PQC implementation

These requirements cannot be met through isolated agency efforts. They require centralized governance and coordinated execution.

2. The state must adopt a phased, statewide migration model

Arizona’s PQC migration must occur in four phases:

Discovery & Inventory — full cryptographic census
Assessment & Prioritization — risk‑based sequencing
Hybrid Deployment — classical + PQC coexistence
Full PQC Transition — statewide cutover

This phased model ensures continuity, reduces operational risk, and aligns with federal guidance.

3. Supply‑chain sovereignty is a critical dependency

Arizona must ensure:

cryptographic components are U.S.‑developed
vendors provide PQC roadmaps
hardware and firmware supply chains are verifiable
no foreign dependencies undermine PQC integrity

This is not optional. It is a statutory requirement and a national‑security imperative.

4. Sector‑specific migration is essential

Different sectors face different constraints:

State agencies — legacy systems, identity infrastructure
Education — distributed networks, low‑resource environments
Public safety — real‑time systems, radio networks
Critical infrastructure — OT/ICS constraints
Vendors — compliance, crypto‑agility, product roadmaps

A one‑size‑fits‑all approach will fail. This report provides tailored guidance for each sector.

5. PQC migration is a governance problem, not a cryptography problem

The technical algorithms are known. The challenge is:

coordination
sequencing
procurement
validation
risk management
cross‑sector alignment
statewide oversight

This report provides the governance architecture required to execute PQC migration at scale.

6. Arizona can become a national leader in PQC modernization

If Arizona executes this roadmap, it will:

meet statutory requirements
exceed federal expectations
strengthen statewide cyber resilience
reduce long‑term risk
position itself as a national model for PQC governance

The opportunity is real. The window is short. The path is clear.

Statewide PQC Migration Framework

Phase	Objective	Key Activities	Outputs
1. Discovery & Inventory	Identify all cryptographic assets	Crypto census, dependency mapping, vendor surveys	Statewide inventory
2. Assessment & Prioritization	Determine migration order	Risk scoring, impact analysis, sector sequencing	Prioritized roadmap
3. Hybrid Deployment	Deploy PQC alongside classical crypto	Hybrid KEMs, certificate upgrades, protocol testing	Hybrid‑mode statewide posture
4. Full PQC Transition	Complete migration	Cutover planning, validation, compliance checks	Statewide PQC compliance

This table is expanded in later chapters.

Chapter 2: Statewide Governance Architecture

Arizona requires a three‑tier governance model:

Statewide PQC Governance Council
- oversight, policy, sequencing, risk management
Sector Implementation Groups
- agency, education, public safety, critical infrastructure
Technical Working Groups
- cryptography, identity, network, OT/ICS, procurement

This structure ensures alignment, accountability, and operational clarity.

Arizona can execute PQC migration at scale — but only through coordinated governance, phased implementation, and sector‑specific modernization. This report provides the complete roadmap.

Key Findings & Strategic Implications

How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This chapter establishes the strategic foundation for Arizona’s statewide PQC migration. It distills the core findings from statutory analysis, statewide readiness assessments, cryptographic inventories, sector interviews, and alignment with the national PQC mandate. These findings define the governance, operational, and modernization realities Arizona must navigate to execute PQC migration at scale.

This is the chapter that sets the tone for the entire report: clear, unambiguous, practitioner‑led, and governance‑anchored.

2.1 — Arizona’s PQC Mandate Is Statutory, Not Optional

HB2809 (2025–2026) is not guidance. It is not advisory. It is not a “best practice.” It is law.

The statute requires:

adoption of NIST‑approved PQC algorithms
statewide cryptographic asset inventories
validation of PQC implementation
U.S.‑based vendor sourcing
CMMC‑aligned cybersecurity posture
a statewide cybersecurity system using PQC

This means:

every agency
every vendor
every system
every protocol
every certificate
every cryptographic dependency must be evaluated and modernized.

Strategic implication: Arizona must treat PQC migration as a statewide modernization program, not a technical upgrade.

2.2 — PQC Migration Is a Governance Problem, Not a Cryptography Problem

The algorithms are known. The standards are finalized. The technical path is clear.

The challenge is:

coordination
sequencing
procurement
validation
risk management
cross‑sector alignment
statewide oversight

Cryptography is the smallest part of PQC migration. Governance is the largest.

Strategic implication: Arizona must establish a centralized governance architecture to coordinate PQC migration across all sectors.

2.3 — Arizona Must Execute a Full Cryptographic Census

No state can migrate what it cannot see. That means Arizona needs a crypto asset inventory in order to determine the ideal migration prioritization.

Arizona must inventory:

TLS endpoints
VPNs
identity systems
certificates
firmware
embedded cryptography
OT/ICS protocols
vendor dependencies
cloud services
APIs
libraries
custom applications
legacy systems

This is the single most important prerequisite for PQC migration.

Strategic implication: Arizona must adopt a standardized, statewide cryptographic inventory methodology to ensure consistency and completeness.

2.4 — Hybrid Modes Are Mandatory for a Multi‑Year Transition

The national PQC mandate requires hybrid modes:

classical + PQC
dual‑algorithm KEMs
transitional certificates
protocol coexistence

Arizona cannot “flip a switch.” Hybrid deployment is the only safe path.

Strategic implication: Arizona must design a multi‑year hybrid cryptographic posture that ensures continuity while PQC is deployed.

2.5 — Supply‑Chain Sovereignty Is a Statutory Requirement

HB2809 requires:

U.S.‑based vendors
U.S.‑developed software
U.S.‑developed hardware
CMMC‑aligned security
verifiable supply chains

This is not a preference. It is a legal requirement.

Strategic implication: Arizona must adopt a PQC supply‑chain sovereignty framework to evaluate vendor readiness and compliance.

2.6 — Sector‑Specific Migration Is Essential

Different sectors face different constraints:

State Agencies

legacy identity systems
outdated protocols
fragmented infrastructure

Education

distributed networks
low‑resource environments
high exposure to phishing

Public Safety

real‑time systems
radio networks
mission‑critical communications

Critical Infrastructure

OT/ICS constraints
long hardware lifecycles
vendor‑locked environments

Vendors

compliance requirements
product roadmaps
crypto‑agility maturity

Strategic implication: Arizona must implement sector‑specific migration plans rather than a single statewide template.

2.7 — PQC Migration Requires a Multi‑Year Roadmap

Arizona must plan for:

2026–2027: discovery, inventory, hybrid pilots
2027–2028: hybrid deployment, certificate modernization
2028–2029: statewide hybrid posture
2029–2030: full PQC transition

This aligns with:

NIST timelines
federal PQC mandates
vendor roadmaps
hardware refresh cycles

Strategic implication: Arizona must adopt a phased, multi‑year implementation roadmap aligned with federal and vendor timelines.

2.8 — PQC Migration Requires Workforce Modernization

Arizona must address:

cryptography literacy gaps
protocol migration skills
hybrid‑mode deployment expertise
vendor evaluation skills
supply‑chain risk analysis
certificate lifecycle management

Strategic implication: Arizona must invest in workforce training and capability development to support PQC migration.

2.9 — PQC Migration Requires Procurement Modernization

Procurement must evolve to include:

PQC readiness requirements
crypto‑agility requirements
supply‑chain sovereignty requirements
vendor roadmap requirements
validation requirements

Strategic implication: Arizona must update procurement templates, RFPs, and vendor evaluation criteria to enforce PQC compliance.

2.10 — PQC Migration Requires Statewide Validation and Compliance

Arizona must validate:

algorithm correctness
hybrid‑mode deployment
certificate modernization
vendor compliance
supply‑chain integrity
system interoperability

Strategic implication: Arizona must establish a statewide PQC validation and compliance program.

2.11 — PQC Migration Is a Strategic Opportunity for Arizona

If executed correctly, Arizona will:

meet statutory requirements
exceed federal expectations
strengthen statewide cyber resilience
reduce long‑term risk
position itself as a national leader in PQC governance

Strategic implication: Arizona can become the national reference model for state‑level PQC modernization.

Arizona’s PQC migration is a governance challenge, a modernization challenge, and a strategic opportunity. The findings in this chapter define the constraints, dependencies, and imperatives that shape the statewide migration roadmap.

Chapter 3: Background and Context

The Quantum Threat, NIST Standards, and Arizona’s Statutory Landscape — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This chapter establishes the foundational context for Arizona’s PQC migration. It explains why PQC is necessary, what standards Arizona must adopt, and how state law, federal mandates, and global cryptographic shifts converge to create the modernization requirements Arizona now faces.

This is the grounding chapter — the one that ensures every policymaker, practitioner, and vendor understands the landscape before the roadmap begins.

3.1 — The Quantum Threat: Why PQC Is Necessary

Quantum computing is no longer a speculative research domain. It is an active, well‑funded, globally competitive race with clear national‑security implications. The threat is not that a cryptographically relevant quantum computer (CRQC) exists today — it is that adversaries are already:

harvesting encrypted data
storing it indefinitely
waiting for quantum decryption capability

This is known as “harvest now, decrypt later” (HNDL).

Why this matters for Arizona

Arizona’s state systems contain:

personal data
health data
tax records
criminal justice data
election‑related data
critical infrastructure telemetry
education records
transportation data
public safety communications

Much of this data has a long confidentiality lifetime — meaning that even if it is stolen today and decrypted in 10–15 years, the harm is still catastrophic.

Key insight

PQC migration is not about protecting against a future quantum computer. It is about protecting against today’s data theft that will be decrypted in the future.

3.2 — The National PQC Mandate

In December 2025, the United States issued the National PQC Modernization Mandate, requiring:

federal agencies to adopt NIST‑approved PQC algorithms
hybrid modes during transition
full cryptographic inventories
vendor PQC readiness
supply‑chain integrity
multi‑year migration roadmaps

This mandate applies directly to:

federal agencies
federal contractors
state systems connected to federal networks
systems handling federal data (CUI, PII, CJIS, HIPAA, IRS 1075, etc.)

Why this matters for Arizona

Arizona agencies interact with federal systems constantly:

Medicaid
SNAP
CJIS
IRS data exchanges
DHS systems
DOT systems
education grants
public safety networks

If Arizona does not modernize, it risks:

federal non‑compliance
data‑sharing restrictions
funding impacts
increased audit exposure

3.3 — NIST PQC Standards (FIPS 203, 204, 205)

NIST finalized the first PQC standards in 2024:

FIPS 203 — ML‑KEM

Post‑quantum key establishment mechanism (KEM). Replaces classical key exchange (e.g., RSA, DH, ECDH).

FIPS 204 — ML‑DSA

Post‑quantum digital signature algorithm. Replaces RSA/ECDSA signatures.

FIPS 205 — SLH‑DSA

Stateless hash‑based signature scheme. Used for high‑assurance, long‑lived signatures.

Hybrid Modes

NIST and CISA require hybrid deployment:

classical + PQC
dual‑algorithm certificates
transitional protocols

This ensures continuity and mitigates early‑implementation risk.

Why this matters for Arizona

HB2809 requires Arizona to adopt NIST‑approved PQC algorithms. These three FIPS standards are the algorithms Arizona must use.

3.4 — Arizona’s Statutory Landscape: HB2809

HB2809 is the first statewide statutory PQC mandate in the United States.

It requires:

1. A statewide cybersecurity system using PQC

Arizona must implement a unified cybersecurity system that uses PQC for:

data‑at‑rest
data‑in‑transit
identity systems
critical infrastructure interfaces

2. Adoption of NIST‑approved PQC algorithms

Arizona must use FIPS 203/204/205.

3. A full cryptographic asset inventory

Every agency must identify:

cryptographic libraries
protocols
certificates
firmware
embedded systems
vendor dependencies

4. U.S.‑based vendor sourcing

Vendors must:

be U.S.‑based
develop software/hardware in the U.S.
meet CMMC‑aligned cybersecurity standards

5. PQC validation and compliance

Arizona must validate that PQC is:

correctly implemented
interoperable
secure
compliant with federal standards

6. Multi‑year modernization

HB2809 implicitly requires a multi‑year migration aligned with:

NIST timelines
federal mandates
vendor roadmaps

3.5 — Arizona’s Current Cryptographic Landscape

Arizona’s cryptographic environment is:

fragmented
legacy‑heavy
vendor‑dependent
inconsistent across agencies
inconsistent across sectors
lacking centralized visibility

Key statewide challenges

outdated TLS configurations
legacy identity systems
long‑lived certificates
OT/ICS systems with hardcoded crypto
vendor‑locked infrastructure
inconsistent patching
limited crypto‑agility

Why this matters

PQC migration cannot succeed without:

visibility
coordination
sequencing
governance

Arizona must modernize its cryptographic posture before PQC deployment.

3.6 — The Global PQC Landscape

Globally, PQC modernization is accelerating:

the EU is adopting PQC for critical infrastructure
Japan is modernizing financial systems
Australia is modernizing government networks
Canada is aligning with NIST
major vendors are releasing PQC‑ready products
cloud providers are deploying hybrid KEMs

Why this matters for Arizona

Arizona’s systems interact with:

global vendors
global supply chains
global cloud infrastructure
global standards bodies

Arizona must ensure:

interoperability
compliance
supply‑chain integrity

3.7 — The Modernization Imperative

Arizona’s PQC migration is driven by:

statutory requirements
federal mandates
global cryptographic shifts
long‑term data protection needs
supply‑chain sovereignty
statewide modernization goals

This is not a technical upgrade. It is a strategic transformation.

Conclusion

Arizona’s PQC migration is shaped by:

the quantum threat
national mandates
NIST standards
statutory requirements
global modernization
statewide cryptographic realities

This chapter establishes the context for the governance architecture and migration roadmap that follow.

Chapter 4 — Threat Model: Quantum Risk, HNDL, and Arizona’s Exposure

Quantum Risk, Harvest‑Now‑Decrypt‑Later, and Arizona’s Exposure — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This chapter defines the threat environment Arizona must plan for. PQC migration is not driven by hypothetical future computers — it is driven by current adversary behavior, long‑lived data sensitivity, and statewide exposure across interconnected systems.

This threat model is intentionally pragmatic, operational, and grounded in the realities of Arizona’s digital ecosystem.

4.1 — The Quantum Threat Landscape

Quantum computing is advancing along three parallel tracks:

1. Government‑funded quantum programs

Nation‑state adversaries are investing billions into:

superconducting qubits
trapped‑ion systems
photonic quantum architectures
error‑corrected logical qubits

These programs are not academic. They are strategic.

2. Commercial quantum development

Major vendors are:

increasing qubit counts
improving coherence times
reducing error rates
developing early logical qubits

Commercial progress accelerates adversarial capability.

3. Intelligence‑driven quantum investment

Adversaries are not waiting for a CRQC. They are preparing for the moment one exists.

Key insight

Arizona must assume that any data stolen today will be decrypted in the future.

4.2 — Harvest‑Now‑Decrypt‑Later (HNDL)

HNDL is the most important threat vector for Arizona.

Adversaries are:

stealing encrypted data now
storing it indefinitely
waiting for quantum decryption capability

This includes:

state tax records
health data
criminal justice data
education records
transportation telemetry
public safety communications
critical infrastructure data
election‑related information

Why HNDL matters for Arizona

Arizona holds data with 10–75 year confidentiality lifetimes.

Examples:

birth records
criminal histories
medical histories
financial data
infrastructure schematics
emergency response plans
identity data
social services data

If stolen today, decrypted later, the harm is still catastrophic.

Key insight

PQC migration is not about future risk. It is about protecting today’s stolen data from tomorrow’s decryption.

4.3 — Arizona’s Exposure Across Sectors

Arizona’s statewide exposure is broad and interconnected.

4.3.1 — State Agencies

Exposure includes:

legacy identity systems
outdated TLS configurations
long‑lived certificates
unpatched applications
vendor‑locked cryptographic libraries

These systems are prime HNDL targets.

4.3.2 — Education (K–12 and Higher Ed)

Exposure includes:

distributed networks
low‑resource environments
high phishing exposure
unmanaged devices
cloud‑based student information systems

Education is one of the most targeted sectors in the U.S.

4.3.3 — Public Safety

Exposure includes:

radio networks
dispatch systems
real‑time communications
mobile data terminals
CJIS‑connected systems

These systems contain sensitive, long‑lived data.

4.3.4 — Critical Infrastructure

Exposure includes:

OT/ICS systems
SCADA networks
hardcoded cryptography
long hardware lifecycles
vendor‑locked environments

These systems cannot be rapidly upgraded.

4.3.5 — Vendors

Exposure includes:

inconsistent crypto‑agility
outdated libraries
unclear PQC roadmaps
foreign supply‑chain dependencies

Vendors represent one of the largest statewide risks.

4.4 — Threat Actors Targeting Arizona

Arizona faces threats from:

Nation‑state adversaries

Motivations:

intelligence collection
long‑term strategic advantage
critical infrastructure mapping
identity data harvesting

Cybercriminal organizations

Motivations:

data theft
extortion
resale of long‑lived data

Supply‑chain adversaries

Motivations:

tampering
backdoors
firmware manipulation

Insider threats

Motivations:

access abuse
credential misuse
data exfiltration

Key insight

PQC migration reduces the value of stolen data — but only if implemented before adversaries decrypt it.

4.5 — Cryptographic Weak Points in Arizona’s Ecosystem

Arizona’s most vulnerable cryptographic dependencies include:

1. Long‑lived certificates

Some certificates have 5–10 year lifespans.

2. Legacy identity systems

Many rely on outdated cryptographic primitives.

3. OT/ICS systems

Often contain hardcoded cryptography.

4. Vendor‑locked infrastructure

Vendors may not support PQC until 2027–2029.

5. Cloud services

Not all cloud providers support hybrid KEMs yet.

6. APIs and microservices

Often use outdated TLS configurations.

7. Firmware and embedded systems

Difficult to update, long replacement cycles.

4.6 — The Risk of Delayed Migration

If Arizona delays PQC migration:

1. HNDL exposure increases

More data stolen today = more data decrypted later.

2. Federal compliance risk increases

Arizona may fail to meet federal PQC requirements.

3. Vendor lock‑in worsens

Legacy systems become harder to migrate.

4. Critical infrastructure becomes more vulnerable

OT/ICS systems require long lead times.

5. Costs increase

Late migration is always more expensive.

6. Interoperability issues emerge

Federal systems will move to PQC before Arizona.

4.7 — Threat Model Summary Table

Threat Vector	Description	Impact on Arizona	Urgency
HNDL	Data stolen now, decrypted later	Long‑lived data exposure	Critical
Legacy Crypto	Outdated algorithms & protocols	Systemic vulnerability	High
Vendor Dependencies	Inconsistent PQC readiness	Migration delays	High
OT/ICS Constraints	Hardcoded crypto, long lifecycles	Critical infrastructure risk	Critical
Supply‑Chain Risk	Foreign dependencies	Statutory non‑compliance	High
Interoperability Gaps	Federal systems migrate first	Operational disruption	Medium

Conclusion

Arizona’s PQC threat model is defined by:

adversaries already harvesting encrypted data
long‑lived data that must remain confidential for decades
statewide exposure across interconnected systems
statutory requirements that mandate modernization
supply‑chain risks that must be mitigated
the need for hybrid deployment during transition

This threat model drives the governance architecture and migration roadmap that follow.

Chapter 5 — Governance Architecture: Statewide Oversight, Sector Coordination, and Implementation Roles

Statewide Oversight, Sector Coordination, and Implementation Roles — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter where the entire modernization effort becomes real. PQC migration is not a cryptography project — it is a statewide governance program that requires structure, authority, sequencing, and accountability.

Arizona cannot execute PQC migration at scale without a governance architecture that:

centralizes oversight
distributes implementation
enforces standards
manages risk
coordinates sectors
validates compliance
ensures continuity of operations

This chapter defines the governance model Arizona must adopt to meet statutory requirements and execute PQC migration across all agencies and sectors.

5.1 — Governance Principles

1. Centralized Oversight, Distributed Execution

A single statewide authority sets policy, standards, and sequencing. Agencies and sectors execute under that guidance.

2. Sector‑Specific Autonomy

Each sector (e.g., public safety, education, critical infrastructure) has unique constraints. Governance must allow tailored implementation.

3. Mandatory Compliance

HB2809 is statutory. Compliance is not optional.

4. Transparency and Reporting

Agencies must report:

inventory results
migration progress
vendor readiness
risk exposure

5. Crypto‑Agility and Future‑Proofing

Governance must support:

hybrid modes
algorithm agility
future PQC updates

6. Supply‑Chain Sovereignty

Vendor selection must align with:

U.S.‑based development
CMMC‑aligned security
verifiable supply chains

These principles guide the governance architecture that follows.

5.2 — The Three‑Tier Governance Model

Arizona must adopt a three‑tier governance structure to coordinate PQC migration across the entire state.

Tier 1 — Statewide PQC Governance Council (SPGC)

Role: Strategic oversight, statewide policy, sequencing, risk management.

This council is the authoritative body responsible for:

statewide PQC policy
migration sequencing
risk prioritization
cross‑sector coordination
compliance enforcement
vendor evaluation
supply‑chain sovereignty oversight
reporting to the Governor and Legislature

Composition

State CIO (Chair)
State CISO
Representatives from:
- Public Safety
- Health Services
- Education
- Transportation
- Critical Infrastructure
- Procurement
- Legal/Compliance
- University research partners
- External PQC advisors (non‑voting)

Key Responsibilities

Approve statewide migration roadmap
Approve cryptographic inventory methodology
Approve hybrid‑mode deployment standards
Approve vendor PQC readiness criteria
Approve supply‑chain sovereignty requirements
Oversee statewide validation and compliance
Publish quarterly progress reports

Tier 2 — Sector Implementation Groups (SIGs)

Role: Sector‑specific planning and execution.

Each major sector forms its own SIG:

State Agencies SIG
Education SIG (K–12 + Higher Ed)
Public Safety SIG
Critical Infrastructure SIG
Vendor Ecosystem SIG

Responsibilities

Conduct sector‑specific cryptographic inventories
Identify sector‑specific constraints
Develop sector‑specific migration plans
Coordinate with vendors and integrators
Implement hybrid‑mode deployment
Report progress to the SPGC

Why SIGs matter

Arizona’s sectors differ dramatically in:

infrastructure maturity
cryptographic dependencies
operational constraints
vendor ecosystems
regulatory requirements

SIGs ensure that migration is tailored, not generic.

Tier 3 — Technical Working Groups (TWGs)

Role: Technical execution, standards development, validation.

TWGs are composed of practitioners and subject‑matter experts.

Core TWGs

Cryptography TWG
Identity & Access Management TWG
Network & Transport Security TWG
OT/ICS & Critical Infrastructure TWG
Cloud & Application Security TWG
Procurement & Vendor Risk TWG
Testing & Validation TWG

Responsibilities

Develop technical standards
Validate hybrid‑mode configurations
Test PQC implementations
Review vendor cryptographic roadmaps
Define certificate modernization requirements
Support agencies during migration
Publish technical guidance

Why TWGs matter

They ensure that:

standards are correct
implementations are secure
migration is technically sound

5.3 — Governance RACI Matrix

A statewide RACI (Responsible, Accountable, Consulted, Informed) matrix ensures clarity.

Function	SPGC	SIGs	TWGs	Agencies
Policy & Standards	A	C	R	I
Cryptographic Inventory	A	R	C	R
Migration Planning	A	R	C	R
Hybrid Deployment	C	R	R	R
Vendor Evaluation	A	C	R	I
Supply‑Chain Sovereignty	A	C	R	I
Validation & Testing	A	C	R	R
Compliance Reporting	A	R	C	R

A = Accountable, R = Responsible, C = Consulted, I = Informed

5.4 — Governance Deliverables

Each governance tier produces specific deliverables.

SPGC Deliverables

Statewide PQC Migration Roadmap
PQC Policy Framework
Supply‑Chain Sovereignty Requirements
Vendor PQC Readiness Criteria
Quarterly Statewide Progress Reports

SIG Deliverables

Sector‑Specific Cryptographic Inventories
Sector Migration Plans
Sector Risk Assessments
Sector Implementation Reports

TWG Deliverables

Technical Standards
Hybrid‑Mode Configuration Guides
Certificate Modernization Standards
PQC Validation Procedures
Vendor Technical Assessments

5.5 — Governance Risks and Mitigations

Risk	Description	Mitigation
Fragmented execution	Agencies act independently	Centralized SPGC oversight
Vendor lock‑in	Vendors delay PQC support	Supply‑chain sovereignty requirements
Inconsistent inventories	Agencies use different methods	Standardized statewide methodology
Hybrid‑mode misconfiguration	Incorrect deployment creates vulnerabilities	TWG validation and testing
Sector misalignment	Different sectors move at different speeds	SIG coordination
Compliance drift	Agencies fall behind	Quarterly reporting + enforcement

5.6 — Why Governance Determines Success

PQC migration fails when:

governance is unclear
roles are undefined
sectors operate independently
vendors dictate timelines
inventories are inconsistent
hybrid modes are misconfigured
validation is weak

PQC migration succeeds when:

oversight is centralized
execution is distributed
standards are enforced
vendors are held accountable
inventories are complete
hybrid modes are validated
compliance is monitored

Governance is the difference between statewide modernization and statewide fragmentation.

Conclusion

Arizona’s PQC migration requires a three‑tier governance architecture that centralizes oversight, distributes execution, and enforces standards. This structure ensures that Arizona can meet statutory requirements, align with federal mandates, and execute PQC migration at scale.

Chapter 6 — Cryptographic Inventory: The Statewide Census Arizona Must Complete First

The Statewide Census Arizona Must Complete First — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the most important operational chapter in the entire report.

If Arizona does not complete a full, standardized, statewide cryptographic inventory, PQC migration will fail — not because the algorithms are wrong, but because the state will be migrating blind.

This chapter defines the methodology, scope, data model, tools, reporting requirements, and governance controls Arizona must use to execute the cryptographic census mandated by HB2809.

This is the blueprint.

6.1 — Why the Cryptographic Inventory Is the Foundation of PQC Migration

Arizona cannot migrate what it cannot see. That is why it needs a complete cryptographic inventory.

A cryptographic inventory is not a list of certificates. It is a complete, multi‑layered census of:

algorithms
protocols
libraries
certificates
keys
firmware
embedded cryptography
vendor dependencies
cloud services
APIs
OT/ICS systems
identity systems
network infrastructure

This inventory is the single most important prerequisite for PQC migration.

Without it:

risk cannot be prioritized
hybrid modes cannot be deployed
vendors cannot be evaluated
migration cannot be sequenced
compliance cannot be validated

HB2809 requires this inventory explicitly. The national PQC mandate requires it implicitly.

6.2 — Statewide Inventory Objectives

Arizona’s cryptographic inventory must:

1. Identify all cryptographic assets

Across all agencies, sectors, and vendors.

2. Map cryptographic dependencies

Including libraries, protocols, and embedded systems.

3. Identify long‑lived data

Data with confidentiality lifetimes of 10–75 years.

4. Identify migration blockers

Legacy systems, vendor‑locked systems, OT/ICS constraints.

5. Support risk‑based prioritization

So Arizona can migrate the highest‑risk systems first.

6. Enable hybrid‑mode deployment

By identifying where hybrid KEMs and transitional certificates are required.

7. Support statewide compliance reporting

To meet statutory and federal requirements.

6.3 — Inventory Scope

The inventory must cover every cryptographic component in Arizona’s statewide ecosystem.

6.3.1 — Software Systems

Web applications
APIs
Microservices
Databases
Identity systems
Authentication flows
Authorization systems
Logging and telemetry systems

6.3.2 — Network Infrastructure

TLS endpoints
VPNs
Firewalls
Load balancers
Proxies
Email systems
DNSSEC configurations

6.3.3 — Certificates and Keys

TLS certificates
code‑signing certificates
S/MIME certificates
SSH keys
API keys
long‑lived signing keys

6.3.4 — Cryptographic Libraries

OpenSSL
BoringSSL
WolfSSL
Microsoft CNG
Java Cryptography Architecture (JCA)
Python cryptography libraries
custom crypto implementations

6.3.5 — Cloud Services

AWS
Azure
Google Cloud
SaaS platforms
identity providers
cloud‑native KMS

6.3.6 — OT/ICS Systems

SCADA
PLCs
RTUs
sensors
actuators
embedded firmware

6.3.7 — Vendor Dependencies

third‑party software
managed services
cloud‑hosted applications
proprietary cryptographic modules

6.3.8 — Data Classification

long‑lived data
regulated data
mission‑critical data
public data

6.4 — Statewide Inventory Methodology

Arizona must adopt a standardized, repeatable, statewide methodology.

The methodology consists of five steps:

Step 1 — Automated Discovery

Tools scan for:

TLS endpoints
certificates
cryptographic libraries
protocol versions
key lengths
cipher suites
embedded crypto

This provides the baseline.

Step 2 — Manual System Owner Surveys

System owners provide:

undocumented crypto
legacy systems
vendor‑locked systems
custom applications
OT/ICS constraints

This fills the gaps automation cannot reach.

Step 3 — Vendor Cryptographic Disclosure

Vendors must provide:

cryptographic bill of materials (CBOM)
PQC readiness roadmap
supply‑chain sovereignty documentation
hybrid‑mode support timelines

This is required by HB2809.

Step 4 — Dependency Mapping

Arizona must map:

libraries → applications
applications → data
data → confidentiality lifetimes
systems → vendors
vendors → supply chains

This identifies migration blockers.

Step 5 — Risk Scoring

Each asset is scored based on:

algorithm strength
data sensitivity
exposure
vendor readiness
migration complexity
operational criticality

This supports statewide prioritization.

6.5 — Statewide Cryptographic Inventory Data Model

Arizona must use a standardized data model to ensure consistency.

Below is the minimum required schema.

Cryptographic Asset Record

Field	Description
Asset ID	Unique identifier
Agency / Sector	Owner
System Name	Application or service
Asset Type	TLS, certificate, library, firmware, etc.
Algorithm	RSA, ECDSA, AES, etc.
Key Length	2048, 3072, 4096, etc.
Protocol	TLS 1.2, TLS 1.3, SSH, IPsec
Library	OpenSSL, JCA, CNG
Vendor	Software/hardware provider
PQC Readiness	Yes/No/Partial
Hybrid Support	Yes/No
Data Sensitivity	Low/Moderate/High
Confidentiality Lifetime	Years
Migration Complexity	Low/Medium/High
Dependencies	Libraries, vendors, hardware
Notes	Additional context

6.6 — Inventory Outputs

The statewide inventory must produce:

1. A complete cryptographic asset database

Centralized, searchable, standardized.

2. A statewide risk map

Identifying high‑risk systems.

3. A migration sequencing model

Based on risk and complexity.

4. A vendor readiness matrix

Identifying compliant and non‑compliant vendors.

5. A supply‑chain sovereignty assessment

Identifying foreign dependencies.

6. A hybrid‑mode deployment plan

Identifying where transitional cryptography is required.

6.7 — Inventory Risks and Mitigations

Risk	Description	Mitigation
Incomplete discovery	Legacy systems missed	Mandatory surveys + TWG review
Vendor non‑cooperation	Vendors refuse to disclose crypto	HB2809 enforcement
Inconsistent data	Agencies use different formats	Standardized statewide schema
OT/ICS blind spots	Embedded crypto not visible	OT/ICS TWG involvement
Cloud opacity	SaaS providers hide crypto details	Contractual PQC requirements
Manual errors	Incorrect reporting	Automated validation

6.8 — Why the Inventory Must Be Completed First

Without a complete inventory:

Arizona cannot prioritize migration
hybrid modes cannot be deployed safely
vendors cannot be evaluated
supply‑chain risks cannot be mitigated
compliance cannot be validated
statewide sequencing cannot be planned

The inventory is the foundation of the entire modernization effort.

Arizona must execute a complete, standardized, statewide cryptographic inventory before PQC migration can begin. This inventory provides the visibility, risk data, and dependency mapping required to build the statewide migration roadmap.

Chapter 7 — Migration Phases: Arizona’s Four‑Phase PQC Modernization Model

Arizona’s Four‑Phase PQC Modernization Model — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter where the statewide modernization effort becomes operational. Arizona cannot migrate to PQC in a single step — not technically, not operationally, not contractually, and not in alignment with NIST or the national PQC mandate.

Arizona must execute PQC migration through four coordinated, statewide phases, each with its own objectives, deliverables, risks, and governance checkpoints.

This chapter defines the official statewide migration model Arizona should adopt.

7.1 — Overview of the Four‑Phase Migration Model

Arizona’s PQC migration must occur in four phases:

Discovery & Inventory
Assessment & Prioritization
Hybrid Deployment
Full PQC Transition

These phases align with:

NIST FIPS 203/204/205
CISA PQC Roadmap
Federal PQC Mandate
HB2809 statutory requirements
Vendor PQC readiness timelines
OT/ICS modernization constraints

Each phase builds on the previous one. Skipping a phase creates statewide risk.

7.2 — Phase 1: Discovery & Inventory

(Covered in detail in Chapter 6 — summarized here for continuity)

Objective

Identify every cryptographic asset across Arizona’s statewide ecosystem.

Key Activities

automated discovery
manual system owner surveys
vendor cryptographic disclosures
OT/ICS field assessments
cloud cryptography mapping
certificate lifecycle analysis

Outputs

statewide cryptographic inventory
dependency map
vendor readiness matrix
supply‑chain sovereignty assessment

Success Criteria

100% agency participation
100% vendor CBOM submissions
complete statewide inventory database

Risks

incomplete discovery
vendor non‑cooperation
OT/ICS blind spots

Mitigation

mandatory reporting
HB2809 enforcement
TWG‑led OT/ICS assessments

7.3 — Phase 2: Assessment & Prioritization

This is where Arizona transforms raw inventory data into a statewide migration roadmap.

Objective

Determine the order in which systems, sectors, and vendors must migrate.

Key Activities

risk scoring
data sensitivity analysis
confidentiality lifetime analysis
migration complexity scoring
vendor readiness evaluation
sector‑specific prioritization
statewide sequencing

Prioritization Criteria

Arizona must prioritize based on:

Data Sensitivity (e.g., criminal justice, health, tax, identity)
Confidentiality Lifetime (10–75 years)
Exposure (internet‑facing, cloud‑hosted, vendor‑managed)
Operational Criticality (public safety, emergency response, transportation)
Migration Complexity (legacy systems, OT/ICS, vendor‑locked systems)
Vendor PQC Readiness (hybrid support, roadmap maturity, supply‑chain sovereignty)

Outputs

statewide migration roadmap
sector‑specific migration plans
vendor prioritization list
hybrid‑mode deployment plan

Success Criteria

roadmap approved by SPGC
sector plans approved by SIGs
hybrid‑mode requirements defined

Risks

misprioritization
vendor delays
sector misalignment

Mitigation

SPGC oversight
quarterly roadmap updates
vendor compliance enforcement

7.4 — Phase 3: Hybrid Deployment

This is the most complex p

hase — and the most important.

Arizona must deploy hybrid cryptography:

classical + PQC
dual‑algorithm KEMs
transitional certificates
hybrid TLS
hybrid VPNs
hybrid identity flows

Hybrid deployment ensures:

continuity
interoperability
vendor compatibility
gradual migration
reduced operational risk

Objective

Deploy hybrid cryptography across all systems statewide.

Key Activities

hybrid KEM deployment
certificate modernization
protocol upgrades
identity system modernization
cloud provider integration
OT/ICS transitional controls
vendor hybrid‑mode validation

Outputs

statewide hybrid cryptographic posture
updated certificates
updated protocols
validated hybrid configurations

Success Criteria

hybrid TLS deployed statewide
hybrid VPNs deployed
hybrid identity flows operational
vendor hybrid support validated

Risks

misconfigured hybrid modes
vendor incompatibility
certificate failures
OT/ICS disruption

Mitigation

TWG validation
staged rollouts
fallback mechanisms
vendor accountability

7.5 — Phase 4: Full PQC Transition

This is the final phase — but it cannot begin until:

hybrid deployment is stable
vendors support PQC natively
OT/ICS systems are upgraded
cloud providers support PQC end‑to‑end
statewide validation is complete

Objective

Transition Arizona to full PQC cryptography.

Key Activities

remove classical algorithms
deploy PQC‑only certificates
update identity systems
update network infrastructure
update OT/ICS firmware
validate PQC‑only configurations
enforce statewide compliance

Outputs

statewide PQC‑only posture
PQC‑only certificates
PQC‑only identity flows
PQC‑only network protocols

Success Criteria

classical crypto removed
PQC‑only systems validated
statewide compliance achieved

Risks

premature cutover
vendor lag
OT/ICS incompatibility
interoperability failures

Mitigation

SPGC approval
TWG validation
phased cutover
rollback plans

7.6 — Statewide Migration Phase Matrix

Phase	Objective	Key Activities	Outputs	Risks
1. Discovery & Inventory	Identify all crypto assets	Automated scans, surveys, vendor CBOMs	Inventory DB	Incomplete discovery
2. Assessment & Prioritization	Build roadmap	Risk scoring, sequencing	Migration roadmap	Misprioritization
3. Hybrid Deployment	Deploy hybrid crypto	Hybrid KEMs, cert upgrades	Hybrid posture	Misconfiguration
4. Full PQC Transition	Remove classical crypto	PQC‑only deployment	PQC‑only posture	Premature cutover

7.7 — Why This Four‑Phase Model Works

This model:

aligns with NIST
aligns with CISA
aligns with federal mandates
aligns with HB2809
supports vendor timelines
supports OT/ICS constraints
reduces operational risk
ensures continuity
enables statewide coordination

It is the only viable path for Arizona to execute PQC migration at scale.

Arizona must execute PQC migration through a structured, phased, statewide modernization model. These four phases provide the roadmap for the governance, technical, and operational work that follows.

Chapter 8 — Sector‑Specific Migration Guidance: Agencies, Education, Public Safety, and Critical Infrastructure

Agencies, Education, Public Safety, and Critical Infrastructure — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This chapter translates the statewide migration model into sector‑specific modernization guidance. Arizona cannot execute PQC migration uniformly across all environments — each sector has distinct constraints, cryptographic dependencies, operational realities, and vendor ecosystems.

This chapter provides tailored, actionable, governance‑aligned guidance for:

State Agencies
Education (K–12 + Higher Ed)
Public Safety
Critical Infrastructure
Vendor Ecosystem

Each sector receives:

a threat profile
cryptographic dependency map
migration blockers
hybrid‑mode requirements
PQC sequencing guidance
validation requirements
compliance expectations

This is the operational heart of the statewide roadmap.

8.1 — State Agencies

State agencies represent the largest and most diverse cryptographic footprint in Arizona. They also hold the highest concentration of long‑lived, high‑sensitivity data.

8.1.1 — Threat Profile

State agencies face:

HNDL exposure of identity, tax, health, and benefits data
legacy systems with outdated crypto
inconsistent patching and protocol configurations
vendor‑locked applications
cloud services with opaque cryptographic implementations

8.1.2 — Cryptographic Dependencies

Common agency dependencies include:

TLS 1.2/1.3 endpoints
SAML/OIDC identity flows
VPNs (IPsec, SSL VPN)
API gateways
Java and .NET crypto libraries
long‑lived certificates
cloud KMS integrations
mainframe and legacy systems

8.1.3 — Migration Blockers

legacy identity systems
outdated load balancers
vendor‑locked applications
long‑lived signing keys
mainframe cryptography
certificate sprawl

8.1.4 — Hybrid‑Mode Requirements

Agencies must deploy:

hybrid TLS (ML‑KEM + classical)
hybrid VPN tunnels
hybrid identity flows
dual‑algorithm certificates
hybrid API authentication

8.1.5 — Migration Sequencing

Identity systems
Internet‑facing applications
Internal APIs
Databases
VPNs
Cloud integrations
Legacy systems
Mainframe systems

8.1.6 — Validation Requirements

hybrid TLS validation
certificate chain validation
identity flow validation
vendor roadmap verification
supply‑chain sovereignty checks

8.1.7 — Compliance Expectations

Agencies must:

complete inventories
submit migration plans
deploy hybrid crypto
validate PQC readiness
report quarterly

8.2 — Education (K–12 and Higher Ed)

Education is one of the most targeted sectors in the United States. It is also one of the least resourced.

Arizona must provide specialized guidance for this sector.

8.2.1 — Threat Profile

Education faces:

high phishing exposure
unmanaged devices
distributed networks
cloud‑hosted student information systems
ransomware targeting

8.2.2 — Cryptographic Dependencies

SIS platforms
LMS platforms
cloud identity providers
Wi‑Fi authentication
TLS endpoints
VPNs (higher ed)
email systems

8.2.3 — Migration Blockers

outdated Wi‑Fi controllers
unmanaged devices
vendor‑locked SIS platforms
inconsistent IT staffing
legacy campus systems

8.2.4 — Hybrid‑Mode Requirements

hybrid TLS for SIS/LMS
hybrid Wi‑Fi authentication
hybrid identity flows
hybrid VPN (higher ed)

8.2.5 — Migration Sequencing

Cloud identity
SIS/LMS platforms
Wi‑Fi authentication
Email systems
Campus applications
VPNs (higher ed)

8.2.6 — Validation Requirements

SIS/LMS vendor PQC readiness
cloud provider hybrid support
Wi‑Fi controller compatibility
certificate modernization

8.2.7 — Compliance Expectations

Education must:

complete inventories
validate vendor readiness
deploy hybrid crypto
report progress to the Education SIG

8.3 — Public Safety

Public safety systems are mission‑critical and real‑time. They cannot tolerate downtime, latency, or cryptographic misconfiguration.

8.3.1 — Threat Profile

Public safety faces:

HNDL exposure of criminal justice data
CJIS compliance requirements
real‑time communication constraints
radio network vulnerabilities
mobile data terminal exposure

8.3.2 — Cryptographic Dependencies

radio networks
dispatch systems
mobile data terminals
CJIS‑connected systems
VPNs
identity systems
body‑worn camera systems

8.3.3 — Migration Blockers

radio systems with hardcoded crypto
vendor‑locked dispatch systems
outdated VPN appliances
legacy CJIS interfaces

8.3.4 — Hybrid‑Mode Requirements

hybrid VPN
hybrid TLS for CJIS interfaces
hybrid identity flows
transitional controls for radio systems

8.3.5 — Migration Sequencing

CJIS‑connected systems
VPNs
dispatch systems
mobile data terminals
radio systems (long‑term)

8.3.6 — Validation Requirements

CJIS compliance
hybrid VPN validation
vendor roadmap verification
radio system modernization plans

8.3.7 — Compliance Expectations

Public safety must:

maintain CJIS compliance
validate hybrid crypto
report to the Public Safety SIG

8.4 — Critical Infrastructure

Critical infrastructure is the most constrained sector. OT/ICS systems have:

long hardware lifecycles
hardcoded cryptography
vendor‑locked firmware
limited update windows

8.4.1 — Threat Profile

Critical infrastructure faces:

nation‑state targeting
OT/ICS exploitation
supply‑chain tampering
long‑lived data exposure
HNDL of operational telemetry

8.4.2 — Cryptographic Dependencies

SCADA systems
PLCs
RTUs
sensors
actuators
embedded firmware
OT/ICS protocols (Modbus, DNP3, etc.)

8.4.3 — Migration Blockers

hardcoded crypto
vendor‑locked firmware
long replacement cycles
limited maintenance windows

8.4.4 — Hybrid‑Mode Requirements

transitional controls
gateway‑level hybrid crypto
network segmentation
compensating controls

8.4.5 — Migration Sequencing

network segmentation
gateway modernization
hybrid crypto at boundaries
firmware updates
hardware replacement (long‑term)

8.4.6 — Validation Requirements

vendor firmware validation
supply‑chain sovereignty checks
hybrid gateway validation
OT/ICS TWG review

8.4.7 — Compliance Expectations

Critical infrastructure operators must:

complete inventories
validate vendor roadmaps
implement transitional controls
report to the Critical Infrastructure SIG

8.5 — Vendor Ecosystem

Vendors represent one of the largest statewide risks.

8.5.1 — Threat Profile

inconsistent crypto‑agility
outdated libraries
foreign supply‑chain dependencies
unclear PQC roadmaps

8.5.2 — Requirements Under HB2809

Vendors must:

be U.S.‑based
develop software/hardware in the U.S.
meet CMMC‑aligned security
provide cryptographic bill of materials (CBOM)
provide PQC readiness roadmaps
support hybrid modes

8.5.3 — Migration Blockers

vendors without PQC roadmaps
foreign cryptographic components
proprietary crypto
outdated libraries

8.5.4 — Validation Requirements

CBOM review
supply‑chain sovereignty validation
hybrid‑mode support verification
roadmap alignment

Each sector requires tailored PQC migration guidance. This chapter provides the operational detail Arizona needs to execute PQC migration across agencies, education, public safety, critical infrastructure, and the vendor ecosystem.

Chapter 9 — Supply‑Chain Sovereignty: Ensuring U.S.‑Based, PQC‑Ready Vendors

Ensuring U.S.‑Based, PQC‑Ready Vendors — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This chapter addresses one of the most strategically important — and statutorily mandated — components of Arizona’s PQC modernization: supply‑chain sovereignty.

HB2809 requires Arizona to use:

U.S.‑based vendors
U.S.‑developed software and hardware
CMMC‑aligned cybersecurity practices
verifiable supply chains
vendors capable of supporting PQC migration

This is not optional. It is the legal, operational, and national‑security foundation of Arizona’s PQC posture.

This chapter defines the framework, criteria, validation model, and risk controls Arizona must use to ensure that every vendor in the statewide ecosystem is PQC‑ready, compliant, and sovereign.

9.1 — Why Supply‑Chain Sovereignty Matters

Cryptography is not just math — it is supply chain.

If Arizona deploys PQC algorithms on top of:

foreign firmware
foreign cryptographic modules
foreign hardware
foreign cloud infrastructure
foreign software libraries

…then the PQC posture is compromised before it begins.

Three reasons sovereignty is essential:

1. PQC is only as strong as the supply chain beneath it

If the hardware or firmware is compromised, PQC cannot protect the system.

2. Adversaries target supply chains because they scale

One compromised vendor = hundreds of compromised systems.

3. HB2809 requires U.S.‑based development

This is a statutory requirement, not a preference.

9.2 — The Arizona Supply‑Chain Sovereignty Framework (ASSF)

Arizona must adopt a statewide framework to evaluate vendor PQC readiness and supply‑chain integrity.

The framework consists of five pillars:

Origin — Where is the software/hardware developed?
Control — Who owns the vendor and its IP?
Security — Does the vendor meet CMMC‑aligned requirements?
Cryptography — Does the vendor support PQC and hybrid modes?
Transparency — Can the vendor provide verifiable documentation?

Each pillar is mandatory.

9.3 — Pillar 1: Origin (U.S.‑Based Development)

Vendors must demonstrate:

U.S. headquarters
U.S. development teams
U.S. code repositories
U.S. hardware manufacturing (where applicable)
U.S. cryptographic module development

Disallowed under HB2809:

foreign development
foreign cryptographic modules
foreign firmware
foreign ownership of critical components

Required Documentation

development location attestation
hardware manufacturing attestation
cryptographic module origin documentation

9.4 — Pillar 2: Control (Ownership and IP Sovereignty)

Arizona must ensure that:

the vendor is not foreign‑owned
the vendor’s IP is not controlled by foreign entities
the vendor is not subject to foreign data‑access laws
the vendor’s supply chain is not dependent on foreign cryptographic components

Required Documentation

ownership structure
IP ownership documentation
foreign influence disclosures
legal jurisdiction disclosures

9.5 — Pillar 3: Security (CMMC‑Aligned Requirements)

Vendors must meet:

CMMC‑aligned cybersecurity practices
secure development lifecycle (SDLC)
vulnerability disclosure programs
incident response capabilities
secure code review processes
insider threat mitigation

Required Documentation

CMMC alignment attestation
SDLC documentation
vulnerability management reports
penetration testing results

9.6 — Pillar 4: Cryptography (PQC Readiness)

Vendors must demonstrate:

1. PQC Roadmap

timelines for ML‑KEM support
timelines for ML‑DSA support
timelines for hybrid‑mode support
timelines for certificate modernization

2. Crypto‑Agility

ability to update algorithms without rewriting applications
support for hybrid KEMs
support for dual‑algorithm certificates

3. PQC Implementation

correct implementation of FIPS 203/204/205
validated cryptographic modules
interoperability testing

Required Documentation

cryptographic bill of materials (CBOM)
PQC roadmap
hybrid‑mode support documentation
crypto‑agility documentation

9.7 — Pillar 5: Transparency (Verifiable Documentation)

Vendors must provide:

CBOM
SBOM
supply‑chain documentation
cryptographic module documentation
firmware origin documentation
PQC readiness documentation

Non‑negotiable requirement:

No vendor may be approved without full documentation.

9.8 — Vendor PQC Readiness Matrix

Vendor Attribute	Requirement	Status Categories
U.S.‑based development	Mandatory	Yes / No
U.S. ownership	Mandatory	Yes / No
CMMC alignment	Mandatory	Yes / Partial / No
PQC roadmap	Mandatory	Mature / Developing / None
Hybrid‑mode support	Mandatory	Yes / Partial / No
Crypto‑agility	Mandatory	Yes / Partial / No
CBOM/SBOM	Mandatory	Complete / Partial / Missing
Supply‑chain sovereignty	Mandatory	Verified / Unverified

Vendors must meet all mandatory requirements to be approved.

9.9 — Vendor Risk Categories

Arizona must classify vendors into three categories:

Category 1 — Fully Sovereign, PQC‑Ready

U.S.‑based
U.S.‑developed
CMMC‑aligned
hybrid‑mode support
PQC roadmap
full documentation

Category 2 — Transitional

U.S.‑based
partial PQC readiness
hybrid support in development
documentation incomplete

Category 3 — Non‑Compliant

foreign development
foreign ownership
no PQC roadmap
no hybrid support
missing documentation

Category 3 vendors must be phased out.

9.10 — Enforcement Mechanisms

Arizona must enforce supply‑chain sovereignty through:

1. Procurement Requirements

PQC readiness required for all new contracts
CBOM/SBOM required for all renewals
supply‑chain documentation required for all vendors

2. Contractual Controls

mandatory PQC timelines
mandatory hybrid support
mandatory crypto‑agility
mandatory vulnerability disclosure

3. Compliance Audits

annual vendor audits
random spot checks
documentation verification

4. Enforcement Actions

contract suspension
contract termination
vendor disqualification

9.11 — Why Supply‑Chain Sovereignty Determines PQC Success

PQC migration fails when:

vendors are not ready
supply chains are compromised
cryptographic modules are foreign‑developed
firmware is unverified
hybrid modes are unsupported

PQC migration succeeds when:

vendors are sovereign
cryptography is U.S.‑developed
supply chains are transparent
hybrid modes are validated
documentation is complete

Supply‑chain sovereignty is the foundation of Arizona’s PQC posture.

Arizona must adopt a rigorous, statewide supply‑chain sovereignty framework to ensure that every vendor is U.S.‑based, PQC‑ready, and compliant with HB2809. This framework protects Arizona from foreign influence, supply‑chain compromise, and vendor‑driven delays.

Chapter 10 — Procurement Modernization: Updating Contracts, RFPs, and Vendor Requirements for PQC

Updating Contracts, RFPs, and Vendor Requirements for PQC — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

Procurement is where PQC modernization becomes enforceable. Governance sets the rules. Procurement makes them real.

Arizona cannot execute PQC migration at scale unless procurement vehicles, contracts, renewals, and RFPs are updated to enforce PQC requirements, supply‑chain sovereignty, and vendor readiness.

This chapter defines the contractual, procedural, and operational changes Arizona must implement to ensure that every vendor, integrator, cloud provider, and product entering the statewide ecosystem is PQC‑ready and compliant with HB2809.

This is the chapter that turns policy into enforceable obligations.

10.1 — Why Procurement Modernization Is Essential

Procurement is the control plane of statewide modernization.

If procurement does not enforce PQC requirements:

non‑compliant vendors will remain in the ecosystem
foreign‑developed cryptographic components will persist
hybrid‑mode support will be inconsistent
PQC migration timelines will slip
supply‑chain sovereignty will be compromised
statewide compliance will fail

Procurement modernization is not administrative. It is strategic cybersecurity governance.

10.2 — Procurement Requirements Under HB2809

HB2809 mandates:

U.S.‑based vendors
U.S.‑developed software and hardware
CMMC‑aligned cybersecurity practices
PQC‑ready cryptographic implementations
verifiable supply‑chain documentation
statewide cryptographic inventory participation

Procurement must enforce these requirements through:

contracts
renewals
RFPs
vendor onboarding
vendor evaluations
compliance audits

10.3 — The Arizona PQC Procurement Framework (APPF)

Arizona must adopt a statewide procurement framework built on six pillars:

PQC Requirements
Hybrid‑Mode Requirements
Crypto‑Agility Requirements
Supply‑Chain Sovereignty Requirements
Documentation Requirements
Compliance & Enforcement Mechanisms

Each pillar is mandatory for all vendors.

10.4 — Pillar 1: PQC Requirements

All vendors must:

support NIST‑approved PQC algorithms (FIPS 203/204/205)
provide PQC implementation timelines
support PQC‑ready cryptographic modules
support PQC‑ready firmware (where applicable)

Contract Language (Recommended)

“Vendor shall implement and maintain support for NIST‑approved post‑quantum cryptographic algorithms, including ML‑KEM, ML‑DSA, and SLH‑DSA, in accordance with Arizona HB2809 and the National PQC Modernization Mandate.”

10.5 — Pillar 2: Hybrid‑Mode Requirements

All vendors must support:

hybrid TLS
hybrid VPN
hybrid identity flows
dual‑algorithm certificates
transitional cryptographic modes

Contract Language (Recommended)

“Vendor shall support hybrid cryptographic modes combining classical and post‑quantum algorithms to ensure interoperability and continuity during Arizona’s PQC transition.”

10.6 — Pillar 3: Crypto‑Agility Requirements

Vendors must demonstrate:

ability to update algorithms without rewriting applications
modular cryptographic architecture
support for future PQC updates
no hardcoded cryptography

Contract Language (Recommended)

“Vendor shall maintain crypto‑agile architectures that allow cryptographic algorithms to be replaced, upgraded, or supplemented without requiring major system redesign.”

10.7 — Pillar 4: Supply‑Chain Sovereignty Requirements

Vendors must:

be U.S.‑based
develop software/hardware in the U.S.
maintain U.S.‑controlled IP
avoid foreign cryptographic components
avoid foreign firmware
avoid foreign data‑access laws

Contract Language (Recommended)

“Vendor shall certify that all cryptographic modules, firmware, and security‑relevant components are developed, maintained, and controlled within the United States.”

10.8 — Pillar 5: Documentation Requirements

Vendors must provide:

CBOM (Cryptographic Bill of Materials)
SBOM (Software Bill of Materials)
supply‑chain documentation
PQC roadmap
hybrid‑mode support documentation
crypto‑agility documentation
vulnerability disclosure policies

Contract Language (Recommended)

“Vendor shall provide complete CBOM and SBOM documentation, including cryptographic algorithms, libraries, modules, and firmware origins.”

10.9 — Pillar 6: Compliance & Enforcement Mechanisms

Procurement must enforce compliance through:

1. Contractual Controls

mandatory PQC timelines
mandatory hybrid support
mandatory documentation
mandatory supply‑chain sovereignty

2. Renewal Controls

no renewal without PQC readiness
no renewal without CBOM/SBOM
no renewal without hybrid support

3. Audit Controls

annual vendor audits
random spot checks
documentation verification

4. Enforcement Actions

contract suspension
contract termination
vendor disqualification

10.10 — Updating RFP Templates

Arizona must update all RFP templates to include:

Mandatory Sections

PQC requirements
hybrid‑mode requirements
crypto‑agility requirements
supply‑chain sovereignty requirements
documentation requirements
validation requirements
compliance reporting requirements

Evaluation Criteria

PQC roadmap maturity
hybrid‑mode readiness
crypto‑agility architecture
supply‑chain transparency
CMMC alignment
documentation completeness

Disqualification Criteria

foreign development
foreign cryptographic components
no PQC roadmap
no hybrid support
incomplete documentation

10.11 — Vendor PQC Readiness Scoring Model

Arizona must score vendors using a standardized model.

Category	Weight	Criteria
PQC Readiness	30%	FIPS 203/204/205 support
Hybrid Support	20%	hybrid TLS/VPN/identity
Crypto‑Agility	20%	modular crypto architecture
Supply‑Chain Sovereignty	20%	U.S.‑based, U.S.‑developed
Documentation	10%	CBOM/SBOM completeness

Vendors must meet minimum thresholds to be approved.

10.12 — Procurement Risks and Mitigations

Risk	Description	Mitigation
Vendor non‑compliance	Vendors fail to meet PQC requirements	Contractual enforcement
Foreign supply‑chain components	Hidden dependencies	CBOM/SBOM + audits
Vendor delays	PQC roadmap slips	Penalty clauses
Incomplete documentation	Vendors hide cryptographic details	Mandatory documentation
Legacy contract lock‑in	Old contracts lack PQC clauses	Renewal enforcement

10.13 — Why Procurement Determines PQC Success

PQC migration fails when:

vendors are not ready
contracts do not enforce requirements
supply chains are opaque
hybrid support is inconsistent
documentation is missing

PQC migration succeeds when:

procurement enforces compliance
vendors are sovereign
hybrid support is mandatory
documentation is complete
contracts align with HB2809

Procurement is the enforcement mechanism of statewide modernization.

Arizona must modernize procurement to enforce PQC requirements, hybrid‑mode support, crypto‑agility, supply‑chain sovereignty, and vendor documentation. Procurement modernization is the mechanism that ensures statewide compliance and protects Arizona from supply‑chain compromise.

Chapter 11 — Workforce Modernization: Skills, Training, and Capability Development for PQC

Skills, Training, and Capability Development for PQC — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

PQC migration is not just a technical modernization effort — it is a workforce transformation. Arizona cannot execute PQC migration at scale unless its workforce has the skills, training, and operational capacity to:

inventory cryptographic assets
deploy hybrid modes
validate PQC implementations
evaluate vendor readiness
enforce supply‑chain sovereignty
manage multi‑year modernization programs

This chapter defines the roles, skills, training pathways, and capability development programs Arizona must establish to support statewide PQC migration.

This is the human architecture behind the technical architecture.

11.1 — Why Workforce Modernization Is Essential

PQC migration fails when:

staff do not understand hybrid modes
cryptographic misconfigurations occur
legacy systems are mishandled
vendors are not properly evaluated
OT/ICS systems are disrupted
identity systems break during transition

PQC migration succeeds when:

staff understand cryptographic dependencies
hybrid modes are deployed correctly
vendors are held accountable
supply‑chain sovereignty is enforced
validation is rigorous
governance is supported by skilled practitioners

Workforce capability is the determinant of operational success.

11.2 — Workforce Roles Required for PQC Migration

Arizona must develop capability across six critical workforce domains:

Cryptography & Protocol Engineering
Identity & Access Management (IAM)
Network & Transport Security
OT/ICS Security
Cloud & Application Security
Procurement & Vendor Risk Management

Each domain requires specialized PQC‑related skills.

11.3 — Domain 1: Cryptography & Protocol Engineering

Required Skills

understanding of classical vs. PQC algorithms
hybrid KEM deployment
certificate modernization
cryptographic library evaluation
crypto‑agility architecture
protocol negotiation (TLS, SSH, IPsec)

Training Pathways

NIST PQC workshops
CISA PQC training modules
vendor‑specific PQC training
Sonoran Desert Security (SDSUG) technical briefings

Roles

cryptography engineers
protocol specialists
certificate authority administrators

11.4 — Domain 2: Identity & Access Management (IAM)

Identity systems are among the highest‑risk components during PQC migration.

Required Skills

hybrid identity flows
PQC‑ready authentication protocols
certificate‑based authentication modernization
cloud identity provider PQC integration
SAML/OIDC modernization

Training Pathways

IAM vendor PQC training
hybrid identity workshops
certificate lifecycle management training

Roles

IAM engineers
identity architects
directory services administrators

11.5 — Domain 3: Network & Transport Security

Network teams must support:

hybrid TLS
hybrid VPN
PQC‑ready load balancers
PQC‑ready proxies
PQC‑ready firewalls

Required Skills

TLS 1.3 hybrid configuration
VPN hybrid KEM deployment
network segmentation for PQC transition
certificate chain validation
traffic inspection modernization

Training Pathways

network vendor PQC training
hybrid TLS workshops
VPN modernization training

Roles

network engineers
firewall administrators
VPN specialists

11.6 — Domain 4: OT/ICS Security

OT/ICS environments require specialized expertise due to:

hardcoded cryptography
long hardware lifecycles
vendor‑locked firmware
limited maintenance windows

Required Skills

gateway‑level hybrid crypto
transitional controls
firmware validation
OT/ICS vendor roadmap evaluation
compensating controls for legacy systems

Training Pathways

OT/ICS vendor PQC training
SCADA modernization workshops
firmware validation training

Roles

OT/ICS engineers
SCADA specialists
industrial cybersecurity analysts

11.7 — Domain 5: Cloud & Application Security

Cloud environments introduce:

opaque cryptographic implementations
vendor‑controlled key management
multi‑tenant risk
API‑level cryptographic dependencies

Required Skills

cloud KMS PQC integration
hybrid TLS for cloud workloads
PQC‑ready API authentication
cloud vendor roadmap evaluation
SBOM/CBOM analysis

Training Pathways

cloud provider PQC training
application security modernization workshops
SBOM/CBOM analysis training

Roles

cloud security engineers
application security engineers
DevSecOps specialists

11.8 — Domain 6: Procurement & Vendor Risk Management

Procurement staff must enforce:

PQC requirements
hybrid‑mode support
crypto‑agility
supply‑chain sovereignty
documentation requirements

Required Skills

CBOM/SBOM analysis
supply‑chain sovereignty evaluation
PQC roadmap assessment
contract modernization
vendor compliance auditing

Training Pathways

procurement modernization workshops
vendor risk management training
supply‑chain sovereignty training

Roles

procurement officers
vendor risk analysts
contract managers

11.9 — Workforce Capability Maturity Model (WCMM)

Arizona must adopt a statewide maturity model to measure workforce readiness.

Level	Description	Statewide Capability
0 — Unprepared	No PQC knowledge	High risk
1 — Aware	Basic PQC awareness	Limited capability
2 — Trained	Staff trained in PQC fundamentals	Moderate capability
3 — Competent	Staff can deploy hybrid modes	Operational capability
4 — Proficient	Staff can validate PQC implementations	High capability
5 — Expert	Staff can architect PQC systems	Statewide leadership

Arizona must reach Level 4 statewide before full PQC transition.

11.10 — Statewide Training Program

Arizona must establish a Statewide PQC Workforce Training Program that includes:

1. Foundational Training

PQC fundamentals
hybrid cryptography
supply‑chain sovereignty

2. Role‑Specific Training

cryptography engineering
IAM modernization
network hybridization
OT/ICS transitional controls
cloud PQC integration

3. Vendor‑Specific Training

cloud providers
network vendors
identity providers
OT/ICS vendors

4. Certification Pathways

PQC practitioner certification
PQC implementation certification
PQC validation certification

5. Continuous Learning

quarterly workshops
annual statewide PQC summit
Sonoran Desert Security (SDSUG) technical briefings

11.11 — Workforce Risks and Mitigations

Risk	Description	Mitigation
Skill gaps	Staff lack PQC knowledge	statewide training
Misconfiguration	Incorrect hybrid deployment	TWG validation
Vendor dependence	Overreliance on vendors	internal capability
OT/ICS disruption	Incorrect handling of legacy systems	specialized training
Cloud opacity	unclear cryptographic controls	cloud training + audits

11.12 — Why Workforce Determines PQC Success

Technology does not migrate itself. Vendors do not enforce themselves. Governance does not implement itself.

PQC migration succeeds when:

staff understand cryptography
hybrid modes are deployed correctly
vendors are held accountable
supply‑chain sovereignty is enforced
validation is rigorous
governance is supported by skilled practitioners

Workforce capability is the operational backbone of statewide PQC modernization.

Arizona must invest in workforce modernization to ensure that staff across all sectors have the skills, training, and capability to execute PQC migration at scale. Workforce capability is the determining factor in the success of Arizona’s PQC modernization program.

Chapter 12 — Hybrid Deployment: The Technical Core of Arizona’s PQC Transition

The Technical Core of Arizona’s PQC Transition — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

Hybrid deployment is the center of gravity for Arizona’s PQC modernization. It is the phase where cryptography becomes operational, where systems begin transitioning from classical to post‑quantum algorithms, and where the risk of misconfiguration is highest.

Hybrid deployment is not optional. It is required by:

NIST
CISA
the National PQC Mandate
HB2809
vendor interoperability constraints
global cryptographic transition realities

This chapter defines the technical, operational, and governance requirements for deploying hybrid cryptography across Arizona’s statewide ecosystem.

This is the chapter that determines whether Arizona’s PQC migration succeeds safely — or fails catastrophically.

12.1 — Why Hybrid Deployment Is Mandatory

Hybrid cryptography combines:

a classical algorithm (e.g., ECDH, RSA)
a post‑quantum algorithm (e.g., ML‑KEM, ML‑DSA)

Hybrid modes ensure:

1. Continuity

Systems continue functioning even if PQC implementations are immature.

2. Interoperability

Vendors and cloud providers migrate at different speeds.

3. Safety

If a PQC algorithm has early‑stage vulnerabilities, classical crypto provides fallback.

4. Compliance

Federal mandates require hybrid modes during transition.

5. Risk Reduction

Hybrid deployment prevents premature cutover.

Hybrid is the only safe path for statewide PQC migration.

12.2 — Hybrid Deployment Architecture

Hybrid deployment affects:

TLS
VPN
identity systems
certificates
APIs
cloud workloads
OT/ICS gateways
firmware update channels

Arizona must adopt a standardized hybrid architecture across all sectors.

12.3 — Hybrid TLS (ML‑KEM + Classical)

Hybrid TLS is the backbone of statewide PQC deployment.

Requirements

ML‑KEM + ECDH hybrid key exchange
ML‑DSA or SLH‑DSA hybrid signatures
TLS 1.3 or higher
dual‑algorithm certificate chains
fallback mechanisms

Deployment Steps

Inventory TLS endpoints
Validate vendor hybrid support
Update load balancers and proxies
Deploy hybrid certificates
Enable hybrid KEM negotiation
Validate interoperability
Monitor performance and errors

Risks

misconfigured cipher suites
certificate chain failures
vendor incompatibility

Mitigation

TWG validation
staged rollouts
fallback to classical crypto

12.4 — Hybrid VPN

VPNs are among the highest‑risk systems during PQC migration.

Requirements

hybrid IPsec or SSL VPN
ML‑KEM + classical key exchange
PQC‑ready firmware
vendor roadmap validation

Deployment Steps

Validate VPN vendor hybrid support
Update firmware
Deploy hybrid KEMs
Validate tunnel negotiation
Test failover
Roll out to remote sites

Risks

tunnel negotiation failures
firmware incompatibility
remote site outages

Mitigation

staged deployment
fallback tunnels
vendor validation

12.5 — Hybrid Identity Systems

Identity systems are the most fragile part of hybrid deployment.

Requirements

hybrid certificate‑based authentication
hybrid SAML/OIDC flows
PQC‑ready identity providers
hybrid MFA flows

Deployment Steps

Inventory identity flows
Validate cloud identity provider PQC readiness
Deploy hybrid certificates
Update authentication endpoints
Validate login flows
Monitor for failures

Risks

authentication failures
SSO outages
certificate chain issues

Mitigation

blue/green deployment
rollback plans
TWG validation

12.6 — Hybrid Certificates

Certificates must support:

classical + PQC signatures
dual‑algorithm certificate chains
PQC‑ready OCSP/CRL infrastructure

Deployment Steps

Update certificate authorities
Deploy hybrid CA hierarchy
Issue hybrid leaf certificates
Update certificate lifecycle management
Validate chain integrity

Risks

chain validation failures
incompatible clients
outdated certificate tooling

Mitigation

TWG testing
vendor validation
staged issuance

12.7 — Hybrid API Security

APIs must support:

hybrid TLS
hybrid authentication tokens
PQC‑ready signing mechanisms

Deployment Steps

Inventory API endpoints
Update API gateways
Deploy hybrid TLS
Update token signing algorithms
Validate client compatibility

Risks

client breakage
token validation failures

Mitigation

versioned API rollout
compatibility testing

12.8 — Hybrid Cloud Integration

Cloud providers migrate at different speeds.

Requirements

hybrid TLS for cloud workloads
PQC‑ready KMS integration
PQC‑ready identity flows
hybrid API authentication

Deployment Steps

Validate cloud provider PQC roadmap
Enable hybrid TLS
Update cloud identity integrations
Validate KMS hybrid support
Update cloud‑native applications

Risks

opaque cryptographic implementations
inconsistent hybrid support

Mitigation

contractual requirements
cloud vendor audits

12.9 — Hybrid OT/ICS Deployment

OT/ICS systems cannot adopt PQC immediately.

Requirements

hybrid gateways
transitional controls
network segmentation
compensating controls

Deployment Steps

Deploy hybrid crypto at network boundaries
Update SCADA gateways
Validate telemetry flows
Implement segmentation
Plan long‑term hardware replacement

Risks

OT/ICS outages
vendor‑locked firmware
limited maintenance windows

Mitigation

TWG oversight
vendor coordination
staged deployment

12.10 — Hybrid Deployment Validation

Arizona must validate:

hybrid TLS
hybrid VPN
hybrid identity flows
hybrid certificates
hybrid cloud integrations
hybrid OT/ICS gateways

Validation Methods

interoperability testing
protocol negotiation testing
certificate chain validation
vendor roadmap verification
supply‑chain sovereignty checks

12.11 — Hybrid Deployment Risks and Mitigations

Risk	Description	Mitigation
Misconfiguration	Incorrect hybrid settings	TWG validation
Vendor incompatibility	Vendors not ready	roadmap enforcement
Certificate failures	chain issues	staged rollout
Identity outages	hybrid auth failures	blue/green deployment
OT/ICS disruption	gateway failures	transitional controls
Cloud opacity	unclear crypto	contractual requirements

12.12 — Why Hybrid Deployment Determines PQC Success

Hybrid deployment is the technical core of Arizona’s PQC transition.

PQC migration fails when:

hybrid modes are misconfigured
vendors are not ready
certificates break
identity systems fail
OT/ICS systems are disrupted

PQC migration succeeds when:

hybrid modes are deployed correctly
vendors are validated
certificates are modernized
identity flows are stable
OT/ICS systems are protected

Hybrid deployment is the bridge between classical and post‑quantum cryptography.

Hybrid deployment is the most technically complex and operationally sensitive phase of Arizona’s PQC migration. This chapter provides the architecture, requirements, and validation model Arizona must use to deploy hybrid cryptography safely and effectively across all sectors.

Chapter 13 — Full PQC Transition: Statewide Cutover, Validation, and Decommissioning of Classical Cryptography

Statewide Cutover, Validation, and Decommissioning of Classical Cryptography — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter where Arizona completes the transformation. Hybrid deployment is the bridge — but full PQC transition is the destination.

This phase is the most sensitive, the most consequential, and the most irreversible. It is where Arizona:

removes classical cryptography
deploys PQC‑only algorithms
validates statewide interoperability
enforces compliance
decommissions legacy systems
finalizes supply‑chain sovereignty
achieves statutory and federal alignment

This chapter defines the cutover model, validation requirements, risk controls, and decommissioning procedures Arizona must follow to complete PQC migration safely.

13.1 — Preconditions for Full PQC Transition

Arizona cannot begin full PQC transition until all of the following are true:

1. Hybrid deployment is stable statewide

No major outages, no certificate failures, no identity disruptions.

2. Vendors support PQC natively

Hybrid is transitional — PQC‑only requires vendor maturity.

3. Cloud providers support PQC end‑to‑end

Identity, KMS, TLS, APIs, and storage must all be PQC‑ready.

4. OT/ICS transitional controls are in place

Critical infrastructure must be protected before cutover.

5. Workforce capability is at Level 4 (Competent)

Staff must be able to validate PQC‑only systems.

6. Statewide validation is complete

Hybrid → PQC‑only transition must be tested thoroughly.

7. SPGC approval is granted

The Statewide PQC Governance Council must authorize cutover.

These preconditions ensure that Arizona does not transition prematurely.

13.2 — The PQC‑Only Architecture

Full PQC transition requires:

ML‑KEM for key establishment
ML‑DSA or SLH‑DSA for signatures
PQC‑only certificates
PQC‑only identity flows
PQC‑only VPN tunnels
PQC‑only TLS
PQC‑only firmware signing
PQC‑only cloud integrations

This architecture removes classical cryptography entirely.

13.3 — PQC‑Only TLS

Requirements

ML‑KEM key exchange
ML‑DSA or SLH‑DSA signatures
PQC‑only certificate chains
TLS 1.3+
PQC‑only cipher suites

Deployment Steps

Replace hybrid certificates with PQC‑only certificates
Disable classical cipher suites
Validate PQC‑only negotiation
Monitor for client incompatibility

Risks

legacy clients break
outdated load balancers fail
certificate chain issues

Mitigation

staged rollout
compatibility testing
fallback environments

13.4 — PQC‑Only VPN

Requirements

ML‑KEM key exchange
PQC‑only tunnel negotiation
PQC‑ready firmware
PQC‑only authentication

Deployment Steps

Validate vendor PQC‑only support
Update firmware
Disable classical negotiation
Validate tunnel stability

Risks

remote site outages
firmware incompatibility

Mitigation

phased deployment
rollback tunnels

13.5 — PQC‑Only Identity Systems

Identity is the highest‑risk component of full transition.

Requirements

PQC‑only certificate‑based authentication
PQC‑only SAML/OIDC flows
PQC‑only MFA signing
PQC‑only token signing

Deployment Steps

Replace hybrid certificates
Update identity provider signing algorithms
Validate login flows
Monitor for failures

Risks

authentication outages
SSO failures

Mitigation

blue/green deployment
rollback identity flows

13.6 — PQC‑Only Certificates

Requirements

PQC‑only CA hierarchy
PQC‑only leaf certificates
PQC‑only OCSP/CRL infrastructure

Deployment Steps

Update CA hierarchy
Issue PQC‑only certificates
Revoke hybrid certificates
Validate certificate chains

Risks

chain validation failures
incompatible clients

Mitigation

TWG validation
staged issuance

13.7 — PQC‑Only Cloud Integration

Cloud providers must support:

PQC‑only TLS
PQC‑only KMS
PQC‑only identity flows
PQC‑only API authentication

Deployment Steps

Validate cloud PQC‑only readiness
Update cloud identity integrations
Update KMS configurations
Validate API flows

Risks

cloud vendor lag
opaque cryptographic implementations

Mitigation

contractual enforcement
cloud vendor audits

13.8 — PQC‑Only OT/ICS Deployment

OT/ICS systems require special handling.

Requirements

PQC‑only gateways
PQC‑only firmware signing
PQC‑only telemetry encryption
hardware replacement (long‑term)

Deployment Steps

Update SCADA gateways
Validate telemetry flows
Deploy PQC‑only firmware
Replace legacy hardware

Risks

OT/ICS outages
vendor‑locked firmware

Mitigation

TWG oversight
vendor coordination
staged deployment

13.9 — Statewide PQC Validation Program

Arizona must validate:

PQC‑only TLS
PQC‑only VPN
PQC‑only identity flows
PQC‑only certificates
PQC‑only cloud integrations
PQC‑only OT/ICS gateways

Validation Methods

protocol negotiation testing
certificate chain validation
interoperability testing
vendor roadmap verification
supply‑chain sovereignty checks

Validation Governance

TWGs conduct validation
SIGs report results
SPGC approves cutover

13.10 — Decommissioning Classical Cryptography

Arizona must decommission:

RSA
ECDH
ECDSA
classical certificate chains
classical VPN tunnels
classical firmware signing
classical identity flows

Decommissioning Steps

Disable classical algorithms
Revoke classical certificates
Remove classical cipher suites
Remove classical firmware signing keys
Validate PQC‑only operation

Risks

legacy systems break
vendor incompatibility

Mitigation

fallback environments
staged decommissioning

13.11 — Statewide Cutover Plan

Arizona must execute cutover in four waves:

Wave 1 — Low‑Risk Systems

internal applications
non‑critical APIs

Wave 2 — Medium‑Risk Systems

cloud workloads
external APIs

Wave 3 — High‑Risk Systems

identity systems
VPNs
TLS endpoints

Wave 4 — Critical Infrastructure

OT/ICS gateways
SCADA systems
telemetry systems

Each wave requires SPGC approval.

13.12 — PQC‑Only Risks and Mitigations

Risk	Description	Mitigation
Premature cutover	PQC‑only before readiness	SPGC approval
Vendor lag	vendors not ready	contractual enforcement
Identity outages	PQC‑only auth failures	blue/green deployment
Certificate failures	PQC‑only chain issues	TWG validation
OT/ICS disruption	gateway failures	staged deployment
Cloud opacity	unclear crypto	audits + contracts

13.13 — Why Full PQC Transition Must Be Controlled

PQC‑only deployment is irreversible. Once classical cryptography is removed:

legacy clients break
outdated systems fail
vendor dependencies surface
cloud integrations may fail

This phase must be:

slow
controlled
validated
governed
staged
reversible (until final cutover)

Full PQC transition is the culmination of Arizona’s modernization effort.

Full PQC transition is the final phase of Arizona’s statewide modernization. This chapter defines the architecture, validation model, cutover plan, and decommissioning procedures required to complete the transition safely and effectively.

Arizona will achieve a PQC‑only statewide posture only when hybrid deployment is stable, vendors are ready, cloud providers support PQC end‑to‑end, and statewide validation is complete.

Chapter 14 — Statewide Validation & Compliance: Ensuring Correctness, Security, and Interoperability

Ensuring Correctness, Security, and Interoperability — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

Hybrid deployment gets Arizona onto the bridge. Full PQC transition gets Arizona across the bridge. Validation and compliance keep the bridge from collapsing.

This chapter defines the statewide validation program Arizona must operate to ensure that:

PQC is implemented correctly
hybrid modes are configured safely
vendors meet statutory requirements
supply‑chain sovereignty is enforced
interoperability is maintained
statewide compliance is measurable and enforceable

This is the chapter that ensures Arizona’s PQC posture is real, not theoretical.

14.1 — Why Validation Is the Most Critical Step After Hybrid Deployment

PQC migration introduces:

new algorithms
new certificate formats
new protocol negotiation paths
new vendor dependencies
new supply‑chain risks
new failure modes

Without validation:

hybrid modes break silently
certificates fail unpredictably
identity systems collapse
VPN tunnels fail
OT/ICS gateways misbehave
cloud integrations fail
vendors misrepresent readiness

Validation is the safety mechanism of statewide PQC modernization.

14.2 — The Arizona PQC Validation Program (APQCVP)

Arizona must establish a statewide validation program with four components:

Technical Validation
Vendor Validation
Supply‑Chain Sovereignty Validation
Compliance Validation

Each component is mandatory.

14.3 — Component 1: Technical Validation

Technical validation ensures that PQC and hybrid modes are implemented correctly.

Systems requiring validation

TLS endpoints
VPN tunnels
identity systems
certificate authorities
cloud integrations
OT/ICS gateways
firmware signing systems
API gateways

Validation Methods

protocol negotiation testing
certificate chain validation
hybrid KEM negotiation testing
PQC‑only negotiation testing
interoperability testing
performance testing
error‑path testing

Validation Tools

Arizona must use:

automated scanners
protocol analyzers
certificate validators
vendor‑provided test suites
cloud provider validation tools

Validation Governance

TWGs conduct validation
SIGs report results
SPGC approves readiness

14.4 — Component 2: Vendor Validation

Vendor validation ensures that vendors:

support hybrid modes
support PQC algorithms
provide CBOM/SBOM
meet supply‑chain sovereignty requirements
meet CMMC‑aligned security requirements
provide accurate PQC roadmaps

Vendor Validation Requirements

Vendors must provide:

PQC roadmap
hybrid‑mode documentation
crypto‑agility documentation
CBOM/SBOM
supply‑chain documentation
firmware origin documentation

Vendor Validation Methods

documentation review
roadmap verification
hybrid‑mode testing
PQC‑only testing
supply‑chain audits
code review (where applicable)

Vendor Validation Governance

Procurement TWG validates documentation
Cryptography TWG validates algorithms
SPGC approves vendor readiness

14.5 — Component 3: Supply‑Chain Sovereignty Validation

Supply‑chain sovereignty validation ensures that:

cryptographic modules are U.S.‑developed
firmware is U.S.‑developed
hardware is U.S.‑controlled
vendors are U.S.‑owned
no foreign cryptographic components exist
no foreign data‑access laws apply

Validation Methods

supply‑chain documentation review
CBOM/SBOM analysis
firmware origin verification
hardware origin verification
ownership structure review
legal jurisdiction review

Governance

Procurement TWG leads
Legal/Compliance teams support
SPGC approves

14.6 — Component 4: Compliance Validation

Compliance validation ensures that:

agencies meet HB2809 requirements
vendors meet contractual requirements
hybrid deployment is complete
PQC‑only transition is validated
supply‑chain sovereignty is enforced

Compliance Requirements

Agencies must:

complete cryptographic inventories
submit migration plans
deploy hybrid crypto
validate PQC readiness
report quarterly

Vendors must:

meet PQC requirements
meet hybrid requirements
meet supply‑chain sovereignty requirements
provide documentation

Compliance Governance

SIGs collect compliance data
TWGs validate technical compliance
SPGC enforces statewide compliance

14.7 — Statewide PQC Validation Matrix

Validation Area	Responsible Group	Method	Output
Hybrid TLS	Network TWG	negotiation testing	validation report
Hybrid VPN	Network TWG	tunnel testing	validation report
Identity Systems	IAM TWG	login flow testing	validation report
Certificates	Crypto TWG	chain validation	CA readiness report
Cloud Integrations	Cloud TWG	API testing	cloud readiness report
OT/ICS Gateways	OT/ICS TWG	telemetry testing	OT/ICS readiness report
Vendor PQC Readiness	Procurement TWG	roadmap verification	vendor readiness matrix
Supply‑Chain Sovereignty	Procurement TWG	documentation review	sovereignty report

14.8 — Statewide PQC Compliance Dashboard

Arizona must maintain a statewide compliance dashboard showing:

Agency Compliance

inventory completion
hybrid deployment status
PQC readiness status
validation results

Vendor Compliance

PQC readiness
hybrid support
supply‑chain sovereignty
documentation completeness

Sector Compliance

public safety
education
critical infrastructure
state agencies

Statewide Metrics

% hybrid TLS deployed
% hybrid VPN deployed
% PQC‑ready identity systems
% PQC‑ready certificates
% PQC‑ready cloud integrations
% PQC‑ready OT/ICS gateways

This dashboard must be updated quarterly.

14.9 — Enforcement Mechanisms

Arizona must enforce compliance through:

1. Contractual Enforcement

mandatory PQC timelines
mandatory hybrid support
mandatory documentation

2. Renewal Enforcement

no renewal without PQC readiness
no renewal without CBOM/SBOM

3. Audit Enforcement

annual audits
random spot checks
documentation verification

4. Governance Enforcement

SPGC authority to mandate remediation
SPGC authority to escalate non‑compliance
SPGC authority to disqualify vendors

14.10 — Validation & Compliance Risks and Mitigations

Risk	Description	Mitigation
Misconfigured hybrid modes	incorrect settings	TWG validation
Vendor misrepresentation	inaccurate roadmaps	audits + enforcement
Supply‑chain opacity	hidden foreign components	CBOM/SBOM + sovereignty checks
Cloud opacity	unclear cryptographic controls	contractual requirements
OT/ICS disruption	gateway failures	staged deployment
Identity outages	PQC‑only auth failures	blue/green deployment

14.11 — Why Validation Determines PQC Success

PQC migration fails when:

hybrid modes are misconfigured
vendors misrepresent readiness
supply chains are compromised
identity systems fail
certificates break
OT/ICS systems are disrupted

PQC migration succeeds when:

validation is rigorous
compliance is enforced
vendors are held accountable
supply‑chain sovereignty is verified
statewide governance is strong

Validation is the quality control of statewide PQC modernization.

Arizona must operate a comprehensive statewide validation and compliance program to ensure that PQC migration is correct, secure, interoperable, and aligned with statutory and federal requirements. Validation is the mechanism that ensures Arizona’s PQC posture is real, resilient, and sovereign.

Chapter 15 — Risk Management: Identifying, Prioritizing, and Mitigating PQC Migration Risks

Identifying, Prioritizing, and Mitigating PQC Migration Risks — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

PQC migration is not a single risk — it is a system of risks that span governance, technology, vendors, supply chains, workforce capability, and operational continuity. This chapter defines the statewide risk management framework Arizona must use to identify, prioritize, and mitigate risks across all phases of PQC modernization.

This is the chapter that ensures Arizona’s modernization effort is resilient, predictable, and governable.

15.1 — Why PQC Migration Introduces New Risk Categories

PQC migration introduces risks that did not exist in classical cryptography transitions:

hybrid‑mode misconfigurations
vendor roadmap failures
supply‑chain sovereignty gaps
PQC algorithm immaturity
certificate chain incompatibilities
identity system fragility
OT/ICS operational constraints
cloud provider opacity
multi‑year transition complexity

These risks must be managed proactively, not reactively.

15.2 — The Arizona PQC Risk Management Framework (APQCRMF)

Arizona must adopt a statewide PQC risk framework built on five pillars:

Risk Identification
Risk Prioritization
Risk Mitigation
Risk Monitoring
Risk Governance

Each pillar is mandatory for statewide modernization.

15.3 — Pillar 1: Risk Identification

Arizona must identify risks across six domains:

1. Cryptographic Risks

hybrid misconfiguration
PQC algorithm vulnerabilities
certificate chain failures
protocol negotiation failures

2. Vendor Risks

incomplete PQC roadmaps
foreign supply‑chain dependencies
outdated cryptographic libraries
proprietary crypto

3. Supply‑Chain Risks

foreign firmware
foreign cryptographic modules
opaque hardware origins
non‑U.S. development

4. Operational Risks

identity outages
VPN failures
TLS negotiation failures
OT/ICS disruption

5. Cloud Risks

opaque cryptographic implementations
inconsistent hybrid support
vendor‑controlled key management

6. Governance Risks

sector misalignment
incomplete inventories
inconsistent reporting
non‑compliant vendors

15.4 — Pillar 2: Risk Prioritization

Arizona must prioritize risks using five criteria:

1. Impact

How severe is the consequence?

2. Likelihood

How probable is the risk?

3. Exposure

How many systems or users are affected?

4. Criticality

Does the system support public safety, health, or essential services?

5. Remediation Complexity

How difficult is the fix?

Risk Levels

Critical — immediate action required
High — action required within 90 days
Medium — action required within 180 days
Low — monitor and address as needed

15.5 — Pillar 3: Risk Mitigation

Arizona must implement mitigation strategies for each risk domain.

15.5.1 — Cryptographic Risk Mitigation

Risks

hybrid misconfiguration
PQC algorithm immaturity
certificate failures

Mitigations

TWG validation
staged deployment
fallback mechanisms
certificate chain testing
protocol negotiation testing

15.5.2 — Vendor Risk Mitigation

Risks

vendor delays
incomplete PQC roadmaps
foreign dependencies

Mitigations

contractual enforcement
PQC roadmap requirements
CBOM/SBOM requirements
supply‑chain sovereignty audits
vendor disqualification

15.5.3 — Supply‑Chain Risk Mitigation

Risks

foreign firmware
foreign cryptographic modules
opaque hardware origins

Mitigations

sovereignty documentation
firmware origin verification
hardware origin verification
procurement enforcement

15.5.4 — Operational Risk Mitigation

Risks

identity outages
VPN failures
TLS negotiation failures
OT/ICS disruption

Mitigations

blue/green deployment
rollback plans
staged cutover
OT/ICS transitional controls
fallback tunnels

15.5.5 — Cloud Risk Mitigation

Risks

cloud vendor lag
opaque cryptographic implementations

Mitigations

contractual requirements
cloud vendor audits
hybrid TLS enforcement
PQC‑ready KMS validation

15.5.6 — Governance Risk Mitigation

Risks

sector misalignment
incomplete inventories
inconsistent reporting

Mitigations

SPGC oversight
standardized inventory schema
quarterly reporting
compliance enforcement

15.6 — Pillar 4: Risk Monitoring

Arizona must monitor risks through:

1. Statewide PQC Dashboard

hybrid deployment status
PQC readiness status
vendor compliance
supply‑chain sovereignty

2. Quarterly Reporting

SIGs submit reports
TWGs validate technical status
SPGC reviews statewide posture

3. Continuous Monitoring

certificate expiration
protocol negotiation failures
VPN tunnel stability
identity flow errors

4. Vendor Monitoring

roadmap updates
documentation updates
supply‑chain changes

15.7 — Pillar 5: Risk Governance

Risk governance ensures:

accountability
transparency
enforcement
escalation

Governance Structure

SPGC — statewide risk authority
SIGs — sector risk owners
TWGs — technical risk validators
Agencies — operational risk owners

Escalation Path

TWG identifies risk
SIG reviews
SPGC escalates
SPGC mandates remediation

15.8 — Statewide PQC Risk Register

Arizona must maintain a statewide risk register with:

risk description
risk owner
impact
likelihood
priority
mitigation plan
status
next review date

This register must be updated monthly.

15.9 — PQC Risk Matrix

Risk Category	Impact	Likelihood	Priority	Mitigation
Hybrid misconfiguration	High	Medium	Critical	TWG validation
Vendor delays	High	High	Critical	contractual enforcement
Supply‑chain compromise	High	Medium	High	sovereignty audits
Identity outages	High	Low	High	blue/green deployment
Certificate failures	Medium	Medium	High	chain validation
OT/ICS disruption	High	Low	High	transitional controls
Cloud vendor lag	Medium	Medium	Medium	contractual requirements
Incomplete inventory	Medium	Low	Medium	standardized schema

15.10 — Why Risk Management Determines PQC Success

PQC migration fails when:

risks are unidentified
risks are unprioritized
risks are unmanaged
vendors are unvalidated
supply chains are opaque
hybrid modes are misconfigured

PQC migration succeeds when:

risks are identified early
risks are prioritized correctly
risks are mitigated proactively
vendors are held accountable
supply chains are sovereign
hybrid modes are validated

Risk management is the stability mechanism of statewide PQC modernization.

Arizona must operate a comprehensive, statewide PQC risk management program to ensure that cryptographic, operational, vendor, supply‑chain, cloud, and governance risks are identified, prioritized, mitigated, and monitored. Risk management is the backbone of a safe, resilient, and sovereign PQC transition.

Chapter 16 — Statewide Roadmap: Multi‑Year Timeline, Milestones, and Sequencing

Multi‑Year Timeline, Milestones, and Sequencing — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that turns the entire report into a coherent, time‑bound, statewide execution plan. It is the chapter policymakers, agency heads, vendors, and auditors will reference most often. It defines when Arizona must act, what must be completed each year, and how statewide sequencing must unfold to meet statutory, federal, and operational requirements.

This roadmap is designed to be:

realistic (aligned with vendor and cloud timelines)
governance‑aligned (SPGC → SIGs → TWGs)
sector‑aware (agencies, education, public safety, critical infrastructure)
risk‑driven (HNDL, long‑lived data, OT/ICS constraints)
federally aligned (NIST, CISA, National PQC Mandate)
statutorily compliant (HB2809)

This is Arizona’s official PQC modernization timeline.

16.1 — Roadmap Overview (2026–2030)

Arizona’s PQC migration must occur in four statewide phases, each mapped to a multi‑year timeline:

Year	Statewide Focus
2026	Inventory, governance, vendor enforcement
2027	Hybrid deployment across all sectors
2028	Hybrid stabilization + PQC‑ready infrastructure
2029	PQC‑only transition preparation
2030	Full PQC transition + classical crypto decommissioning

This timeline aligns with:

NIST algorithm maturity
vendor hybrid support timelines
cloud provider PQC roadmaps
OT/ICS hardware refresh cycles
HB2809 statutory deadlines

16.2 — 2026: Foundation Year

Inventory, Governance, Vendor Enforcement

2026 is the year Arizona builds the foundation for the entire modernization effort.

Statewide Objectives

complete cryptographic inventory
establish governance architecture
enforce vendor documentation requirements
publish statewide PQC roadmap
begin hybrid pilot programs

Key Milestones

SPGC operational
SIGs established
TWGs staffed and active
statewide inventory schema approved
vendor CBOM/SBOM submissions required
supply‑chain sovereignty documentation collected
hybrid TLS pilot in 2–3 agencies
hybrid VPN pilot in 1–2 agencies

End‑of‑Year Deliverables

statewide cryptographic inventory
statewide risk map
statewide vendor readiness matrix
statewide hybrid deployment plan

16.3 — 2027: Hybrid Deployment Year

Statewide rollout of hybrid cryptography

2027 is the year Arizona deploys hybrid cryptography across all sectors.

Statewide Objectives

deploy hybrid TLS statewide
deploy hybrid VPN statewide
deploy hybrid identity flows
modernize certificate authorities
update cloud integrations
deploy hybrid OT/ICS gateways

Key Milestones

hybrid TLS on all internet‑facing systems
hybrid VPN for all remote access
hybrid identity flows for all agencies
hybrid certificates issued statewide
cloud providers validated for hybrid support
OT/ICS transitional controls deployed

End‑of‑Year Deliverables

statewide hybrid cryptographic posture
hybrid certificate hierarchy
hybrid identity modernization report
cloud hybrid readiness report

16.4 — 2028: Stabilization & Infrastructure Modernization

Strengthening hybrid deployment and preparing for PQC‑only systems

2028 is the year Arizona stabilizes hybrid deployment and prepares for PQC‑only transition.

Statewide Objectives

validate hybrid deployment
modernize legacy systems
update OT/ICS hardware where possible
enforce vendor PQC readiness
update cloud KMS and identity systems
begin PQC‑only pilot programs

Key Milestones

hybrid TLS validated statewide
hybrid VPN validated statewide
hybrid identity validated statewide
PQC‑ready CA hierarchy deployed
PQC‑ready cloud integrations validated
PQC‑only pilot in 1–2 low‑risk systems

End‑of‑Year Deliverables

statewide hybrid validation report
PQC‑ready infrastructure report
PQC‑only pilot results
updated statewide roadmap

16.5 — 2029: PQC‑Only Transition Preparation

Preparing for statewide cutover

2029 is the year Arizona prepares for PQC‑only transition.

Statewide Objectives

deploy PQC‑only certificates in pilot environments
validate PQC‑only TLS
validate PQC‑only VPN
validate PQC‑only identity flows
validate PQC‑only cloud integrations
validate PQC‑only OT/ICS gateways
finalize decommissioning plans for classical crypto

Key Milestones

PQC‑only TLS validated in pilot systems
PQC‑only VPN validated in pilot systems
PQC‑only identity flows validated
PQC‑only cloud integrations validated
PQC‑only OT/ICS gateways validated
statewide cutover plan approved by SPGC

End‑of‑Year Deliverables

statewide PQC‑only readiness report
statewide cutover plan
classical crypto decommissioning plan

16.6 — 2030: Full PQC Transition

Statewide cutover + decommissioning of classical cryptography

2030 is the year Arizona completes PQC migration.

Statewide Objectives

deploy PQC‑only TLS statewide
deploy PQC‑only VPN statewide
deploy PQC‑only identity flows statewide
deploy PQC‑only certificates statewide
deploy PQC‑only cloud integrations
deploy PQC‑only OT/ICS gateways
decommission classical cryptography

Key Milestones

classical crypto disabled
hybrid certificates revoked
PQC‑only certificates deployed
PQC‑only identity flows operational
PQC‑only VPN operational
PQC‑only OT/ICS gateways operational

End‑of‑Year Deliverables

statewide PQC‑only posture
statewide compliance report
statewide supply‑chain sovereignty report
statewide decommissioning report

16.7 — Statewide Sequencing Model

Arizona must sequence migration across sectors in the following order:

State Agencies
Education
Public Safety
Cloud Providers
Critical Infrastructure

This sequencing reflects:

data sensitivity
confidentiality lifetimes
operational criticality
vendor readiness
OT/ICS constraints

16.8 — Roadmap Governance

SPGC Responsibilities

approve roadmap
update roadmap annually
enforce statewide sequencing
validate readiness for each phase

SIG Responsibilities

implement sector‑specific timelines
report progress quarterly
escalate risks

TWG Responsibilities

validate technical readiness
test hybrid and PQC‑only systems
publish technical guidance

16.9 — Roadmap Risks and Mitigations

Risk	Description	Mitigation
Vendor delays	PQC roadmap slips	contractual enforcement
Cloud vendor lag	cloud not ready	audits + contracts
OT/ICS constraints	hardware not replaceable	transitional controls
Identity fragility	PQC‑only auth failures	blue/green deployment
Certificate failures	chain issues	TWG validation
Sector misalignment	inconsistent progress	SPGC oversight

16.10 — Why the Roadmap Matters

The roadmap is the operational backbone of Arizona’s PQC modernization.

Without it:

agencies drift
vendors stall
sectors misalign
risks accumulate
compliance fails

With it:

modernization is coordinated
vendors are accountable
risks are managed
compliance is enforceable
Arizona becomes the national model for PQC governance

This chapter provides Arizona with a multi‑year, governance‑aligned, sector‑aware, risk‑driven roadmap for PQC migration. It defines the timeline, milestones, sequencing, and governance controls required to execute PQC modernization at statewide scale.

Chapter 17 — Sector Roadmaps: Detailed Timelines for Agencies, Education, Public Safety, and Critical Infrastructure

Detailed Timelines for Agencies, Education, Public Safety, and Critical Infrastructure — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

Chapter 16 established the statewide roadmap. Chapter 17 now drills down into sector‑specific timelines — the operational detail required for each domain to execute PQC migration in alignment with statewide sequencing, vendor readiness, and statutory requirements.

Each sector receives:

a 4‑year migration timeline
annual milestones
sector‑specific dependencies
sector‑specific risks
sector‑specific validation requirements
sector‑specific vendor expectations

This chapter is the operational blueprint for agencies, schools, public safety organizations, and critical infrastructure operators.

17.1 — State Agencies Roadmap (2026–2030)

Largest footprint, highest data sensitivity, most complex dependencies

State agencies lead the statewide migration because they hold:

the most long‑lived data
the most regulated data
the most interconnected systems
the most identity dependencies

2026 — Inventory & Governance Integration

Milestones

complete cryptographic inventory
map identity flows
map TLS endpoints
map VPN dependencies
collect CBOM/SBOM from all vendors
enforce supply‑chain sovereignty documentation
begin hybrid TLS pilot

Dependencies

statewide inventory schema
vendor documentation

2027 — Hybrid Deployment

Milestones

hybrid TLS on all internet‑facing systems
hybrid VPN for all remote access
hybrid identity flows deployed
hybrid certificates issued
cloud integrations updated

Dependencies

identity provider hybrid support
network vendor hybrid support

2028 — Stabilization & Modernization

Milestones

hybrid TLS validated
hybrid VPN validated
hybrid identity validated
legacy systems modernized
PQC‑ready CA hierarchy deployed
PQC‑only pilot in low‑risk systems

Dependencies

cloud PQC readiness
vendor PQC roadmaps

2029–2030 — PQC‑Only Transition

Milestones

PQC‑only TLS
PQC‑only VPN
PQC‑only identity flows
PQC‑only certificates
classical crypto decommissioned

Dependencies

statewide SPGC approval
PQC‑only validation

17.2 — Education Roadmap (K–12 + Higher Ed)

High attack surface, low resources, heavy cloud dependence

Education requires a lighter‑weight, cloud‑aligned roadmap.

2026 — Inventory & Vendor Enforcement

Milestones

inventory SIS/LMS platforms
inventory Wi‑Fi controllers
inventory cloud identity providers
require CBOM/SBOM from SIS/LMS vendors
require PQC roadmaps from cloud identity providers

Dependencies

vendor cooperation
cloud documentation

2027 — Hybrid Deployment

Milestones

hybrid TLS for SIS/LMS
hybrid identity flows
hybrid Wi‑Fi authentication (where supported)
hybrid VPN for higher ed

Dependencies

cloud provider hybrid support
Wi‑Fi vendor hybrid support

2028 — Stabilization

Milestones

validate hybrid SIS/LMS
validate hybrid identity
validate hybrid Wi‑Fi
update campus applications
begin PQC‑only pilot in non‑critical systems

Dependencies

cloud PQC readiness
vendor PQC roadmaps

2029–2030 — PQC‑Only Transition

Milestones

PQC‑only SIS/LMS
PQC‑only identity flows
PQC‑only Wi‑Fi authentication
PQC‑only VPN (higher ed)
classical crypto decommissioned

Dependencies

cloud PQC‑only support
campus hardware refresh cycles

17.3 — Public Safety Roadmap (2026–2030)

Mission‑critical, real‑time, zero‑downtime tolerance

Public safety systems require the most cautious sequencing.

2026 — Inventory & CJIS Alignment

Milestones

inventory dispatch systems
inventory radio systems
inventory mobile data terminals
inventory CJIS‑connected systems
require CBOM/SBOM from all vendors
validate CJIS alignment with hybrid requirements

Dependencies

CJIS policy updates
vendor documentation

2027 — Hybrid Deployment

Milestones

hybrid TLS for CJIS interfaces
hybrid VPN for all public safety networks
hybrid identity flows
transitional controls for radio systems

Dependencies

CJIS hybrid guidance
radio vendor support

2028 — Stabilization & OT/ICS Integration

Milestones

validate hybrid VPN
validate hybrid TLS
validate hybrid identity
deploy hybrid gateways for radio/dispatch systems
begin PQC‑only pilot in low‑risk systems

Dependencies

radio firmware updates
dispatch vendor roadmaps

2029–2030 — PQC‑Only Transition

Milestones

PQC‑only VPN
PQC‑only TLS
PQC‑only identity flows
PQC‑only dispatch gateways
long‑term radio modernization

Dependencies

radio hardware refresh cycles
CJIS PQC‑only guidance

17.4 — Critical Infrastructure Roadmap (2026–2035)

Most constrained, longest timelines, highest national‑security impact

Critical infrastructure requires a longer timeline due to:

hardcoded cryptography
vendor‑locked firmware
long hardware lifecycles
limited maintenance windows

This roadmap extends beyond 2030.

2026 — Inventory & Vendor Roadmaps

Milestones

inventory SCADA systems
inventory PLCs, RTUs, sensors
inventory firmware signing systems
require CBOM/SBOM from all OT/ICS vendors
require PQC roadmaps
require supply‑chain sovereignty documentation

Dependencies

vendor cooperation
OT/ICS TWG involvement

2027 — Hybrid Boundary Deployment

Milestones

deploy hybrid crypto at network boundaries
deploy hybrid SCADA gateways
deploy transitional controls
segment networks

Dependencies

gateway vendor hybrid support
SCADA vendor hybrid support

2028 — Stabilization & Firmware Planning

Milestones

validate hybrid gateways
validate telemetry flows
plan firmware updates
plan hardware refresh cycles
begin PQC‑only pilot in isolated OT networks

Dependencies

vendor firmware updates
hardware availability

2029–2030 — PQC‑Only Gateway Deployment

Milestones

deploy PQC‑only SCADA gateways
deploy PQC‑only telemetry encryption
deploy PQC‑only firmware signing
begin hardware replacement

Dependencies

PQC‑only firmware
PQC‑only gateway support

2031–2035 — Full OT/ICS Hardware Replacement

Milestones

replace legacy PLCs
replace legacy RTUs
replace legacy sensors
deploy PQC‑only hardware
decommission classical OT crypto

Dependencies

capital planning
vendor hardware cycles

17.5 — Cross‑Sector Comparison Table

Sector	Fastest Migration	Most Complex	Most Constrained	Longest Timeline
State Agencies	Yes	High	Medium	2026–2030
Education	Yes	Medium	Low	2026–2030
Public Safety	No	Very High	High	2026–2030
Critical Infrastructure	No	Extreme	Extreme	2026–2035

17.6 — Why Sector Roadmaps Matter

Sector roadmaps ensure:

alignment with statewide sequencing
realistic timelines based on sector constraints
vendor accountability
risk‑based prioritization
sector‑specific validation
statutory compliance

Without sector roadmaps:

agencies move at different speeds
vendors exploit ambiguity
critical infrastructure lags
public safety risks increase
statewide compliance fails

Sector roadmaps are the operational backbone of statewide PQC modernization.

Conclusion

This chapter provides detailed, sector‑specific timelines for PQC migration across state agencies, education, public safety, and critical infrastructure. These roadmaps ensure that each sector moves in alignment with statewide governance, vendor readiness, and statutory requirements.

Chapter 18 — Implementation Playbooks: Technical Guides for TLS, VPN, Identity, Cloud, and OT/ICS

Technical Guides for TLS, VPN, Identity, Cloud, and OT/ICS — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter practitioners will use daily. It is the hands‑on, operational, “how to actually do this” chapter — the one that turns governance, roadmaps, and policy into repeatable technical procedures.

Each playbook is written to be:

vendor‑agnostic
NIST‑aligned
CISA‑aligned
HB2809‑compliant
operationally realistic
safe for hybrid deployment
ready for PQC‑only transition

These playbooks are the canonical technical reference for Arizona’s statewide PQC modernization.

18.1 — TLS Playbook

Hybrid TLS → PQC‑Only TLS

TLS is the front door of Arizona’s digital ecosystem. It is the most visible, most widely deployed, and most frequently misconfigured cryptographic surface.

This playbook ensures TLS is migrated safely.

18.1.1 — TLS Hybrid Requirements

Hybrid TLS must support:

ML‑KEM + ECDH (hybrid key exchange)
ML‑DSA or SLH‑DSA + ECDSA (hybrid signatures)
TLS 1.3 or higher
dual‑algorithm certificate chains
fallback mechanisms

18.1.2 — TLS Hybrid Deployment Steps

Step 1 — Inventory TLS Endpoints

Collect:

certificate chains
cipher suites
protocol versions
load balancer/proxy configurations
cloud TLS termination points

Step 2 — Validate Vendor Hybrid Support

Confirm:

hybrid KEM support
hybrid signature support
PQC‑ready firmware/software
fallback behavior

Step 3 — Deploy Hybrid Certificates

Issue:

hybrid CA certificates
hybrid intermediate certificates
hybrid leaf certificates

Step 4 — Enable Hybrid Cipher Suites

Enable:

ML‑KEM + ECDH
ML‑DSA or SLH‑DSA + ECDSA

Disable:

RSA key exchange
outdated cipher suites

Step 5 — Validate Negotiation

Test:

client compatibility
fallback behavior
certificate chain validation

Step 6 — Monitor & Stabilize

Monitor:

handshake failures
negotiation patterns
performance impacts

18.1.3 — TLS PQC‑Only Transition Steps

Step 1 — Replace Hybrid Certificates

Issue:

PQC‑only CA hierarchy
PQC‑only leaf certificates

Step 2 — Disable Classical Cipher Suites

Disable:

ECDH
ECDSA
RSA

Step 3 — Validate PQC‑Only Negotiation

Test:

ML‑KEM negotiation
ML‑DSA/SLH‑DSA signatures
client compatibility

Step 4 — Revoke Hybrid Certificates

Ensure:

OCSP/CRL updated
hybrid chains removed

18.2 — VPN Playbook

Hybrid VPN → PQC‑Only VPN

VPNs are mission‑critical and extremely sensitive to cryptographic changes.

18.2.1 — VPN Hybrid Requirements

Hybrid VPN must support:

ML‑KEM + classical key exchange
PQC‑ready firmware
hybrid authentication
fallback tunnels

18.2.2 — VPN Hybrid Deployment Steps

Step 1 — Validate Vendor Support

Confirm:

hybrid IPsec/IKEv2
hybrid SSL VPN
PQC‑ready firmware

Step 2 — Update Firmware

Apply:

PQC‑ready firmware
hybrid KEM support

Step 3 — Enable Hybrid Tunnels

Configure:

hybrid key exchange
hybrid authentication

Step 4 — Validate Tunnel Negotiation

Test:

tunnel establishment
rekeying
fallback behavior

Step 5 — Roll Out to Remote Sites

Use:

staged deployment
rollback tunnels

18.2.3 — VPN PQC‑Only Transition Steps

Step 1 — Enable PQC‑Only Negotiation

Disable:

classical key exchange
classical authentication

Step 2 — Validate Tunnel Stability

Test:

long‑duration tunnels
rekeying
failover

18.3 — Identity Playbook

Hybrid Identity → PQC‑Only Identity

Identity is the most fragile component of PQC migration.

18.3.1 — Identity Hybrid Requirements

Hybrid identity must support:

hybrid certificate‑based authentication
hybrid SAML/OIDC flows
hybrid MFA signing
hybrid token signing

18.3.2 — Identity Hybrid Deployment Steps

Step 1 — Inventory Identity Flows

Identify:

SAML flows
OIDC flows
certificate‑based auth
MFA signing mechanisms

Step 2 — Validate Cloud Identity Provider Support

Confirm:

hybrid signing
hybrid TLS
hybrid token validation

Step 3 — Deploy Hybrid Certificates

Update:

IdP signing keys
SP trust stores
MFA signing keys

Step 4 — Validate Login Flows

Test:

SSO flows
MFA flows
token validation

Step 5 — Monitor & Stabilize

Monitor:

authentication failures
token validation errors

18.3.3 — Identity PQC‑Only Transition Steps

Step 1 — Replace Hybrid Signing Keys

Deploy:

PQC‑only signing keys
PQC‑only MFA keys

Step 2 — Update Trust Stores

Remove:

classical keys
hybrid keys

Step 3 — Validate PQC‑Only Authentication

Test:

SSO
MFA
token validation

18.4 — Cloud Playbook

Hybrid Cloud → PQC‑Only Cloud

Cloud providers are the largest dependency in Arizona’s PQC migration.

18.4.1 — Cloud Hybrid Requirements

Cloud hybrid must support:

hybrid TLS
hybrid identity flows
hybrid API authentication
hybrid KMS

18.4.2 — Cloud Hybrid Deployment Steps

Step 1 — Validate Cloud Provider Roadmap

Confirm:

hybrid TLS support
hybrid KMS support
hybrid identity support

Step 2 — Enable Hybrid TLS

Update:

load balancers
API gateways
cloud‑native services

Step 3 — Update Identity Integrations

Configure:

hybrid SAML/OIDC
hybrid MFA

Step 4 — Validate API Flows

Test:

token signing
token validation
TLS negotiation

18.4.3 — Cloud PQC‑Only Transition Steps

Step 1 — Enable PQC‑Only TLS

Disable:

classical cipher suites

Step 2 — Update KMS

Enable:

PQC‑only key wrapping
PQC‑only key exchange

Step 3 — Validate PQC‑Only Identity

Test:

SSO
MFA
token validation

18.5 — OT/ICS Playbook

Hybrid Gateways → PQC‑Only OT/ICS

OT/ICS systems require the most specialized handling.

18.5.1 — OT/ICS Hybrid Requirements

Hybrid OT/ICS must support:

hybrid gateways
transitional controls
network segmentation
compensating controls

18.5.2 — OT/ICS Hybrid Deployment Steps

Step 1 — Deploy Hybrid Gateways

Place:

hybrid crypto at network boundaries
hybrid SCADA gateways

Step 2 — Validate Telemetry Flows

Test:

latency
packet integrity
protocol compatibility

Step 3 — Implement Segmentation

Segment:

SCADA networks
PLC networks
sensor networks

18.5.3 — OT/ICS PQC‑Only Transition Steps

Step 1 — Deploy PQC‑Only Gateways

Replace:

hybrid gateways
transitional controls

Step 2 — Update Firmware

Deploy:

PQC‑only firmware
PQC‑only signing

Step 3 — Replace Hardware (Long‑Term)

Replace:

PLCs
RTUs
sensors

18.6 — Why Playbooks Matter

Playbooks ensure:

repeatability
consistency
safety
interoperability
compliance
vendor accountability

Without playbooks:

hybrid deployment becomes chaotic
PQC‑only transition becomes dangerous
vendors exploit ambiguity
agencies misconfigure systems
statewide compliance fails

Playbooks are the operational doctrine of Arizona’s PQC modernization.

Conclusion

This chapter provides the technical implementation playbooks Arizona needs to deploy hybrid and PQC‑only cryptography across TLS, VPN, identity, cloud, and OT/ICS systems. These playbooks ensure safe, consistent, and validated modernization across all sectors.

Chapter 19 — Testing & Validation Frameworks: Ensuring Correctness Across All Systems and Vendors

Ensuring Correctness Across All Systems and Vendors — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This chapter is the technical quality‑assurance engine of the entire statewide PQC modernization effort. It defines the frameworks, procedures, tooling, and governance Arizona must use to prove that:

hybrid cryptography is deployed correctly
PQC‑only systems function safely
vendors meet their obligations
supply‑chain sovereignty is real
interoperability is maintained
statewide compliance is measurable

This is the chapter that ensures Arizona’s PQC posture is correct, secure, interoperable, and sovereign — not just on paper, but in practice.

19.1 — Why Testing & Validation Must Be a Dedicated Statewide Program

PQC migration introduces:

new algorithms
new certificate formats
new protocol negotiation paths
new vendor dependencies
new failure modes
new supply‑chain risks

Without a dedicated validation program:

hybrid modes silently fail
PQC‑only systems break
identity systems collapse
VPN tunnels fail
OT/ICS gateways misbehave
cloud integrations fail
vendors misrepresent readiness

Testing is the only safeguard against statewide cryptographic failure.

19.2 — The Arizona PQC Testing & Validation Framework (APQCTVF)

Arizona must operate a statewide validation framework with six components:

Protocol Validation
Certificate Validation
Identity Validation
VPN Validation
Cloud Validation
OT/ICS Validation

Each component is mandatory and governed by TWGs.

19.3 — Component 1: Protocol Validation

TLS, SSH, IPsec, QUIC, and all transport protocols

Objectives

ensure hybrid negotiation works
ensure PQC‑only negotiation works
ensure fallback behavior is correct
ensure no classical‑only negotiation remains

Validation Tests

hybrid KEM negotiation
PQC‑only KEM negotiation
hybrid signature negotiation
PQC‑only signature negotiation
cipher suite validation
downgrade attack resistance
performance testing

Failure Modes

negotiation failure
fallback to classical
certificate chain mismatch
client incompatibility

19.4 — Component 2: Certificate Validation

Hybrid → PQC‑only certificate ecosystems

Objectives

validate hybrid certificate chains
validate PQC‑only certificate chains
validate OCSP/CRL behavior
validate CA hierarchy correctness

Validation Tests

chain building
chain verification
signature verification
revocation checking
client compatibility

Failure Modes

chain validation failure
unsupported signature algorithms
OCSP/CRL failures

19.5 — Component 3: Identity Validation

The most fragile and highest‑risk component

Objectives

validate hybrid identity flows
validate PQC‑only identity flows
validate MFA signing
validate token signing and verification

Validation Tests

SAML login
OIDC login
MFA flows
token signing
token validation
trust store updates

Failure Modes

SSO outages
MFA failures
token rejection
trust chain mismatch

19.6 — Component 4: VPN Validation

Mission‑critical, real‑time, zero‑tolerance for failure

Objectives

validate hybrid VPN tunnels
validate PQC‑only VPN tunnels
validate rekeying
validate failover

Validation Tests

tunnel establishment
tunnel rekey
tunnel failover
long‑duration stability
remote site compatibility

Failure Modes

tunnel negotiation failure
rekey failure
firmware incompatibility

19.7 — Component 5: Cloud Validation

Cloud providers are the largest dependency in the ecosystem

Objectives

validate hybrid TLS
validate hybrid identity
validate hybrid API authentication
validate PQC‑only TLS
validate PQC‑only identity
validate PQC‑only KMS

Validation Tests

TLS negotiation
SSO flows
MFA flows
API token signing
API token validation
KMS key wrapping

Failure Modes

cloud vendor lag
opaque cryptographic behavior
inconsistent hybrid support

19.8 — Component 6: OT/ICS Validation

The most constrained and highest‑impact environment

Objectives

validate hybrid gateways
validate PQC‑only gateways
validate telemetry flows
validate firmware signing
validate hardware compatibility

Validation Tests

latency testing
packet integrity
protocol compatibility
firmware signature verification
gateway failover

Failure Modes

telemetry disruption
gateway failure
firmware rejection

19.9 — Statewide PQC Test Suites

Arizona must maintain official statewide test suites for:

TLS
VPN
identity
certificates
cloud integrations
OT/ICS gateways

These test suites must be:

standardized
repeatable
vendor‑agnostic
updated annually
aligned with NIST and CISA

19.10 — Vendor Testing Requirements

Vendors must:

pass statewide hybrid test suites
pass statewide PQC‑only test suites
provide test results
provide CBOM/SBOM
provide supply‑chain documentation
provide firmware origin documentation

Vendors that fail validation must be:

remediated
restricted
or disqualified

19.11 — Statewide PQC Validation Lab

Arizona must operate a centralized validation lab that:

tests hybrid configurations
tests PQC‑only configurations
tests vendor products
tests cloud integrations
tests OT/ICS gateways
tests certificate chains
tests identity flows

This lab is the technical enforcement arm of statewide governance.

19.12 — Continuous Validation

Validation is not a one‑time event. Arizona must validate continuously:

Daily

certificate expiration
TLS negotiation failures
VPN tunnel stability

Weekly

identity flow errors
cloud API failures

Monthly

vendor roadmap updates
supply‑chain documentation updates

Quarterly

statewide compliance reporting
SPGC review

19.13 — Validation Governance

TWGs

conduct technical validation
publish test suites
review vendor results

SIGs

coordinate sector validation
report results

SPGC

approve readiness
enforce compliance
escalate failures

19.14 — Why Testing & Validation Determine PQC Success

PQC migration fails when:

hybrid modes are misconfigured
PQC‑only systems break
vendors misrepresent readiness
supply chains are compromised
identity systems fail
OT/ICS systems are disrupted

PQC migration succeeds when:

validation is rigorous
testing is continuous
vendors are held accountable
supply‑chain sovereignty is verified
statewide governance is strong

Testing is the quality‑control engine of statewide PQC modernization.

Conclusion

This chapter defines the testing and validation frameworks Arizona must use to ensure that hybrid and PQC‑only cryptography are deployed correctly, safely, and consistently across all sectors. Validation is the mechanism that ensures Arizona’s PQC posture is real, resilient, and sovereign.

Chapter 20 — Monitoring & Observability: Statewide Telemetry for PQC Migration and Stability

Statewide Telemetry for PQC Migration and Stability — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

Hybrid deployment introduces new cryptographic behaviors. PQC‑only transition introduces new failure modes. Vendor ecosystems introduce new risks. OT/ICS introduces new operational constraints. Cloud providers introduce new opacity.

Monitoring and observability are the only way Arizona can see what is actually happening.

This chapter defines the statewide telemetry architecture Arizona must operate to ensure:

hybrid cryptography is functioning
PQC‑only systems remain stable
certificate chains behave correctly
identity flows remain reliable
VPN tunnels remain stable
cloud integrations remain secure
OT/ICS gateways remain operational
vendors remain compliant

This is the chapter that gives Arizona eyes on the entire cryptographic ecosystem.

20.1 — Why Monitoring & Observability Are Mandatory

PQC migration introduces:

new algorithms
new negotiation paths
new certificate formats
new vendor dependencies
new cloud behaviors
new OT/ICS telemetry patterns

Without monitoring:

hybrid failures go undetected
PQC‑only outages cascade
identity failures become statewide incidents
certificate chain issues break applications
VPN tunnels silently fall back to classical crypto
cloud providers regress without notice
OT/ICS gateways fail without warning

Monitoring is the early‑warning system of statewide PQC modernization.

20.2 — The Arizona PQC Observability Framework (APQCOF)

Arizona must operate a statewide observability framework with six telemetry domains:

TLS Telemetry
VPN Telemetry
Identity Telemetry
Certificate Telemetry
Cloud Telemetry
OT/ICS Telemetry

Each domain has its own metrics, alerts, dashboards, and governance.

20.3 — TLS Telemetry

Monitoring hybrid and PQC‑only TLS negotiation

Metrics

hybrid negotiation success rate
PQC‑only negotiation success rate
fallback to classical crypto
handshake failures
certificate chain failures
cipher suite usage
client compatibility failures

Alerts

fallback to classical detected
PQC‑only negotiation failure
certificate chain validation failure
spike in handshake errors

Dashboards

statewide TLS posture
hybrid vs PQC‑only negotiation
certificate chain health

20.4 — VPN Telemetry

Monitoring hybrid and PQC‑only VPN tunnels

Metrics

tunnel establishment success rate
rekey success rate
hybrid vs PQC‑only negotiation
tunnel drop rate
firmware version compliance
remote site compatibility

Alerts

tunnel negotiation failure
fallback to classical
firmware mismatch
rekey failure

Dashboards

statewide VPN posture
hybrid vs PQC‑only tunnel distribution
remote site stability

20.5 — Identity Telemetry

Monitoring hybrid and PQC‑only identity flows

Identity is the most fragile component of PQC migration.

Metrics

SSO success rate
MFA success rate
token signing failures
token validation failures
trust chain mismatches
hybrid vs PQC‑only signing

Alerts

spike in authentication failures
token validation errors
certificate trust failures

Dashboards

statewide identity posture
hybrid vs PQC‑only identity flows
MFA reliability

20.6 — Certificate Telemetry

Monitoring hybrid and PQC‑only certificate ecosystems

Metrics

certificate expiration
certificate chain validation
OCSP/CRL availability
hybrid vs PQC‑only certificate usage
CA hierarchy health

Alerts

certificate expiration within 30 days
OCSP/CRL outage
chain validation failure

Dashboards

statewide certificate posture
hybrid vs PQC‑only certificate distribution
CA hierarchy health

20.7 — Cloud Telemetry

Monitoring cloud provider PQC readiness and behavior

Cloud providers are the largest dependency in the ecosystem.

Metrics

hybrid TLS negotiation
PQC‑only TLS negotiation
identity flow reliability
API token signing/validation
KMS PQC readiness
cloud service regression

Alerts

fallback to classical
cloud identity failures
cloud KMS failures
cloud API negotiation failures

Dashboards

statewide cloud PQC posture
cloud provider readiness
cloud identity reliability

20.8 — OT/ICS Telemetry

Monitoring hybrid and PQC‑only OT/ICS gateways

OT/ICS telemetry must be minimal, safe, and non‑intrusive.

Metrics

gateway negotiation success
telemetry latency
packet integrity
firmware signature validation
hardware compatibility

Alerts

telemetry disruption
gateway negotiation failure
firmware signature rejection

Dashboards

statewide OT/ICS PQC posture
gateway stability
firmware integrity

20.9 — Statewide PQC Monitoring Architecture

Arizona must deploy a three‑layer monitoring architecture:

Layer 1 — Local Telemetry

Collected at:

agencies
schools
public safety networks
OT/ICS sites

Layer 2 — Sector Dashboards

Managed by SIGs:

State Agencies SIG
Education SIG
Public Safety SIG
Critical Infrastructure SIG

Layer 3 — Statewide Dashboard

Managed by SPGC:

statewide hybrid posture
statewide PQC‑only posture
statewide vendor compliance
statewide supply‑chain sovereignty

20.10 — Telemetry Retention & Analysis

Arizona must retain telemetry for:

1 year for operational analysis
3 years for compliance
7 years for critical infrastructure

Telemetry must be analyzed for:

regression detection
vendor misbehavior
supply‑chain anomalies
cryptographic downgrade attempts
identity anomalies
OT/ICS instability

20.11 — Monitoring Governance

TWGs

define metrics
define alerts
validate telemetry

SIGs

operate sector dashboards
escalate anomalies

SPGC

operate statewide dashboard
enforce compliance
mandate remediation

20.12 — Why Monitoring Determines PQC Success

PQC migration fails when:

hybrid failures go unnoticed
PQC‑only outages cascade
certificate chains break silently
identity systems fail without warning
VPN tunnels fall back to classical
cloud providers regress
OT/ICS gateways fail

PQC migration succeeds when:

telemetry is comprehensive
alerts are actionable
dashboards are accurate
governance is strong
vendors are monitored
supply chains are visible

Monitoring is the nervous system of statewide PQC modernization.

Conclusion

This chapter defines the statewide monitoring and observability architecture Arizona must operate to ensure that hybrid and PQC‑only cryptography remain stable, secure, and interoperable across all sectors. Monitoring is the mechanism that gives Arizona real‑time visibility into its cryptographic posture and ensures statewide resilience.

Chapter 21 — Incident Response & Continuity: Handling PQC Failures, Outages, and Vendor Breakage

Handling PQC Failures, Outages, and Vendor Breakage — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that protects Arizona when things go wrong.

PQC migration introduces new failure modes, new vendor dependencies, new cryptographic behaviors, and new operational risks. Hybrid deployment and PQC‑only transition are powerful — but fragile if not backed by a statewide incident response and continuity framework.

This chapter defines the incident response playbooks, continuity strategies, rollback procedures, and governance escalation paths Arizona must use to handle:

hybrid cryptographic failures
PQC‑only outages
certificate chain breakage
identity system failures
VPN tunnel failures
cloud provider regressions
OT/ICS gateway failures
vendor roadmap collapses
supply‑chain sovereignty breaches

This is the chapter that ensures Arizona can survive PQC failures without statewide disruption.

21.1 — Why PQC Requires a New Incident Response Model

PQC migration introduces risks that traditional IR models cannot handle:

hybrid negotiation failures
PQC‑only signature incompatibilities
certificate chain mismatches
cloud provider regressions
vendor firmware failures
OT/ICS gateway instability
supply‑chain sovereignty violations

Traditional IR models assume:

stable algorithms
predictable certificate behavior
mature vendor ecosystems
stable cloud cryptography

PQC breaks all of those assumptions.

Arizona must operate a PQC‑specific IR and continuity framework.

21.2 — The Arizona PQC Incident Response Framework (APQCIRF)

Arizona’s PQC IR framework consists of six components:

Detection
Classification
Containment
Rollback
Remediation
Governance Escalation

Each component is mandatory.

21.3 — Component 1: Detection

Identifying PQC failures early

Detection relies on:

statewide telemetry (Chapter 20)
certificate monitoring
TLS/VPN negotiation logs
identity flow logs
cloud provider alerts
OT/ICS gateway telemetry
vendor notifications

Common PQC Failure Indicators

spike in TLS handshake failures
fallback to classical crypto
certificate chain validation errors
SSO/MFA failures
VPN tunnel negotiation failures
cloud API negotiation failures
OT/ICS telemetry disruption
firmware signature rejection

21.4 — Component 2: Classification

Determining severity and scope

Arizona must classify PQC incidents into four levels:

Level 1 — Localized PQC Degradation

single system
no public impact
hybrid fallback functioning

Level 2 — Sector‑Level PQC Failure

multiple systems in one sector
hybrid fallback partially functioning

Level 3 — Statewide PQC Failure

multiple sectors affected
hybrid fallback failing
identity or VPN outages

Level 4 — Critical Infrastructure PQC Failure

OT/ICS disruption
SCADA gateway failure
telemetry corruption
no fallback available

Level 4 incidents require immediate SPGC intervention.

21.5 — Component 3: Containment

Stopping the spread of cryptographic failure

Containment strategies include:

1. Fallback to Classical Crypto

Used when hybrid or PQC‑only fails.

2. Isolation of Affected Systems

Used for identity, VPN, and cloud failures.

3. Gateway Isolation (OT/ICS)

Used when telemetry or control channels are unstable.

4. Certificate Chain Freezing

Temporarily halting issuance of new certificates.

5. Vendor Containment

Blocking updates or integrations from failing vendors.

Containment must be fast, automated, and reversible.

21.6 — Component 4: Rollback

Returning systems to a known‑good cryptographic state

Rollback is the most important continuity mechanism in PQC migration.

Rollback Scenarios

hybrid TLS → classical TLS
PQC‑only TLS → hybrid TLS
PQC‑only identity → hybrid identity
PQC‑only VPN → hybrid VPN
PQC‑only certificates → hybrid certificates
PQC‑only OT/ICS gateways → hybrid gateways

Rollback Requirements

pre‑validated fallback configurations
pre‑issued fallback certificates
pre‑tested fallback tunnels
pre‑tested identity fallback flows
pre‑tested OT/ICS fallback gateways

Rollback must be instant, not reactive.

21.7 — Component 5: Remediation

Fixing the underlying issue

Remediation depends on the failure type.

21.7.1 — TLS Remediation

update cipher suites
update certificates
update load balancer/proxy configs
update client compatibility lists

21.7.2 — Identity Remediation

update signing keys
update trust stores
update SAML/OIDC metadata
update MFA signing algorithms

21.7.3 — VPN Remediation

update firmware
update tunnel negotiation settings
update authentication mechanisms

21.7.4 — Cloud Remediation

enforce vendor rollback
update cloud TLS settings
update cloud identity integrations
update cloud API gateways

21.7.5 — OT/ICS Remediation

update gateway firmware
update telemetry encryption settings
update segmentation
update compensating controls

21.7.6 — Vendor Remediation

require updated CBOM/SBOM
require updated PQC roadmap
require updated firmware
require supply‑chain sovereignty documentation

21.8 — Component 6: Governance Escalation

Ensuring accountability and statewide coordination

Escalation Path

TWG identifies and analyzes the issue
SIG coordinates sector response
SPGC determines statewide impact
SPGC mandates rollback or remediation
SPGC enforces vendor accountability

SPGC Emergency Powers

mandate statewide rollback
suspend vendor integrations
revoke certificates
isolate cloud integrations
isolate OT/ICS gateways
require emergency updates

21.9 — PQC Incident Categories & Playbooks

Arizona must maintain playbooks for:

1. Hybrid TLS Failure

fallback to classical
reissue hybrid certificates

2. PQC‑Only TLS Failure

rollback to hybrid
validate PQC‑only chain

3. Identity Failure

rollback to hybrid identity
update signing keys

4. VPN Failure

rollback to hybrid tunnels
update firmware

5. Cloud Regression

enforce vendor rollback
isolate affected services

6. OT/ICS Gateway Failure

isolate gateway
rollback to hybrid
validate firmware

7. Vendor Supply‑Chain Breach

immediate vendor suspension
supply‑chain sovereignty audit

21.10 — Continuity Requirements

Arizona must maintain:

1. Fallback Configurations

For TLS, VPN, identity, cloud, OT/ICS.

2. Fallback Certificates

Hybrid and classical.

3. Fallback Tunnels

Pre‑validated VPN tunnels.

4. Fallback Identity Flows

Hybrid SAML/OIDC.

5. Fallback Gateways

Hybrid OT/ICS gateways.

6. Offline CA Capability

For emergency certificate issuance.

7. Vendor Freeze Mechanisms

To block updates from failing vendors.

21.11 — Why Incident Response Determines PQC Success

PQC migration fails when:

failures cascade
outages spread
vendors regress
cloud providers break compatibility
identity systems collapse
OT/ICS gateways fail

PQC migration succeeds when:

failures are detected early
containment is immediate
rollback is instant
remediation is coordinated
governance is strong
vendors are held accountable

Incident response is the resilience engine of statewide PQC modernization.

Conclusion

This chapter defines the incident response and continuity framework Arizona must use to handle PQC failures, outages, vendor breakage, and supply‑chain sovereignty violations. It ensures that Arizona can withstand cryptographic instability and maintain statewide continuity during the PQC transition.

Chapter 22 — Governance & Oversight: SPGC, SIGs, TWGs, and Statewide Authority Structures

SPGC, SIGs, TWGs, and Statewide Authority Structures — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that defines who is in charge, who has authority, who executes, and how Arizona maintains statewide alignment across a multi‑year, multi‑sector, multi‑vendor PQC modernization effort.

Governance is not an accessory — it is the operating system of PQC migration. Without governance:

agencies drift
vendors stall
sectors misalign
risks accumulate
compliance collapses
supply‑chain sovereignty erodes

With governance:

modernization is coordinated
vendors are accountable
risks are managed
compliance is enforceable
statewide posture is coherent

This chapter defines the Statewide PQC Governance Council (SPGC), Sector Implementation Groups (SIGs), and Technical Working Groups (TWGs) — the three‑tier governance model that makes statewide PQC modernization possible.

22.1 — The Three‑Tier Governance Model

Arizona must operate a three‑tier governance architecture:

SPGC — Statewide PQC Governance Council Authority, enforcement, statewide alignment
SIGs — Sector Implementation Groups Sector‑level coordination and reporting
TWGs — Technical Working Groups Technical execution, validation, and testing

This model ensures:

statewide authority
sector‑specific execution
technical correctness

22.2 — SPGC: Statewide PQC Governance Council

The apex authority for PQC modernization

The SPGC is the strategic, statutory, and enforcement authority for Arizona’s PQC transition.

22.2.1 — SPGC Responsibilities

1. Statewide Strategy & Roadmap

approve statewide PQC roadmap
update roadmap annually
enforce statewide sequencing

2. Statewide Policy & Standards

approve statewide PQC policies
approve statewide hybrid requirements
approve statewide PQC‑only requirements

3. Vendor Oversight

approve vendor readiness
enforce supply‑chain sovereignty
mandate vendor remediation
disqualify non‑compliant vendors

4. Risk & Incident Governance

approve statewide risk register
mandate remediation
authorize rollback
declare statewide PQC emergencies

5. Compliance Enforcement

enforce HB2809 requirements
enforce documentation requirements
enforce hybrid deployment
enforce PQC‑only transition

22.2.2 — SPGC Authority

SPGC has the authority to:

mandate statewide cutover
mandate statewide rollback
suspend vendor integrations
revoke certificates
isolate cloud integrations
isolate OT/ICS gateways
require emergency updates
escalate to state leadership

SPGC is the final decision‑maker for all PQC matters.

22.3 — SIGs: Sector Implementation Groups

Sector‑level coordination and reporting

SIGs ensure that each sector executes PQC migration in alignment with statewide strategy.

Arizona must operate four SIGs:

State Agencies SIG
Education SIG
Public Safety SIG
Critical Infrastructure SIG

22.3.1 — SIG Responsibilities

1. Sector Roadmap Execution

implement sector‑specific timelines
coordinate sector‑level migration
escalate sector risks

2. Sector Reporting

quarterly reporting to SPGC
sector compliance dashboards
sector vendor readiness reports

3. Sector Validation

coordinate TWG validation
ensure sector systems pass hybrid tests
ensure sector systems pass PQC‑only tests

4. Sector Incident Response

coordinate sector‑level containment
coordinate sector‑level rollback
escalate to SPGC when needed

SIGs are the operational managers of PQC modernization.

22.4 — TWGs: Technical Working Groups

Technical execution, validation, and testing

TWGs are the technical engine of statewide PQC modernization.

Arizona must operate six TWGs:

Cryptography TWG
Identity TWG
Network/VPN TWG
Cloud TWG
OT/ICS TWG
Procurement & Supply‑Chain TWG

22.4.1 — TWG Responsibilities

1. Technical Standards

define hybrid TLS standards
define hybrid VPN standards
define hybrid identity standards
define PQC‑only standards

2. Validation & Testing

operate statewide validation lab
publish test suites
validate vendor products
validate cloud integrations
validate OT/ICS gateways

3. Technical Guidance

publish implementation playbooks
publish configuration guides
publish troubleshooting guides

4. Incident Response

analyze failures
recommend rollback
recommend remediation
support SIGs during incidents

TWGs are the technical authority for PQC modernization.

22.5 — Governance Flow: How Decisions Move Through the System

1. TWGs → SIGs

TWGs validate technical readiness and report results to SIGs.

2. SIGs → SPGC

SIGs consolidate sector results and escalate risks to SPGC.

3. SPGC → Statewide

SPGC makes statewide decisions and enforces compliance.

This flow ensures:

technical accuracy
sector alignment
statewide authority

22.6 — Governance Artifacts

Arizona must maintain:

1. Statewide PQC Roadmap

Approved by SPGC.

2. Sector Roadmaps

Managed by SIGs.

3. Technical Standards

Published by TWGs.

4. Validation Reports

Produced by TWGs.

5. Compliance Dashboards

Maintained by SIGs and SPGC.

6. Risk Register

Owned by SPGC.

7. Vendor Readiness Matrix

Owned by Procurement TWG.

22.7 — Governance Risks & Mitigations

Risk	Description	Mitigation
Sector misalignment	sectors move at different speeds	SPGC enforcement
Vendor non‑compliance	vendors fail to meet requirements	procurement enforcement
Technical inconsistency	hybrid modes misconfigured	TWG standards
Cloud opacity	unclear cryptographic behavior	cloud audits
OT/ICS constraints	long hardware cycles	transitional controls
Reporting gaps	incomplete sector reporting	quarterly SPGC reviews

22.8 — Why Governance Determines PQC Success

PQC migration fails when:

governance is weak
vendors are unregulated
sectors drift
risks accumulate
compliance collapses

PQC migration succeeds when:

governance is strong
authority is clear
vendors are accountable
sectors are aligned
validation is rigorous
compliance is enforced

Governance is the control plane of statewide PQC modernization.

Conclusion

This chapter defines the governance and oversight architecture Arizona must operate to execute PQC modernization at statewide scale. SPGC provides authority, SIGs provide coordination, and TWGs provide technical execution. Together, they form the governance system that ensures Arizona’s PQC posture is coherent, resilient, and sovereign.

Chapter 23 — Communication & Change Management: Statewide Messaging for Agencies, Vendors, and the Public

Statewide Messaging for Agencies, Vendors, and the Public — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This chapter is where Arizona learns how to talk about PQC — internally, externally, across agencies, across sectors, to vendors, and to the public.

PQC modernization is not just a technical transformation. It is a behavioral, institutional, and cultural transformation.

If Arizona does not communicate clearly:

agencies will misunderstand requirements
vendors will delay or misrepresent readiness
public safety organizations will fear disruption
educators will feel overwhelmed
critical infrastructure operators will resist change
the public will misunderstand the purpose of PQC
policymakers will lose visibility
compliance will collapse

Communication is the force multiplier of statewide PQC modernization.

23.1 — Why Communication & Change Management Matter

PQC migration is:

multi‑year
multi‑sector
multi‑vendor
high‑risk
high‑complexity
high‑visibility

Without structured communication:

timelines drift
vendors stall
sectors misalign
misinformation spreads
resistance increases
compliance fails

With structured communication:

expectations are clear
timelines are understood
vendors are accountable
sectors stay aligned
the public understands the purpose
policymakers see progress

Communication is the glue that holds the statewide program together.

23.2 — The Arizona PQC Communication Framework (APQCCF)

Arizona must operate a statewide communication framework with five channels:

Executive Communication
Agency Communication
Vendor Communication
Sector Communication
Public Communication

Each channel has its own audience, purpose, and messaging style.

23.3 — Executive Communication

For policymakers, state leadership, and oversight bodies

Objectives

maintain statewide alignment
communicate progress
communicate risks
communicate vendor compliance
secure funding and support

Artifacts

quarterly SPGC briefings
annual statewide PQC report
statewide risk register summaries
vendor compliance summaries

Tone

strategic
concise
risk‑aware
outcome‑focused

23.4 — Agency Communication

For CIOs, CISOs, IT directors, and technical staff

Objectives

communicate requirements
communicate timelines
communicate technical standards
communicate validation results
communicate incident response procedures

Artifacts

implementation playbooks
configuration guides
validation reports
incident response procedures
sector‑specific roadmaps

Tone

precise
technical
actionable

23.5 — Vendor Communication

For software vendors, hardware vendors, cloud providers, integrators

Objectives

enforce HB2809 requirements
enforce supply‑chain sovereignty
enforce PQC roadmaps
enforce hybrid support
enforce documentation requirements

Artifacts

vendor requirements documents
CBOM/SBOM templates
supply‑chain sovereignty attestation forms
hybrid/PQC‑only test suites
vendor readiness scorecards

Tone

authoritative
unambiguous
compliance‑focused

23.6 — Sector Communication

For education, public safety, critical infrastructure, and agencies

Objectives

align sector timelines
share sector‑specific risks
share sector‑specific guidance
coordinate sector‑level validation
coordinate sector‑level incident response

Artifacts

SIG briefings
sector dashboards
sector validation reports
sector incident summaries

Tone

collaborative
sector‑aware
operational

23.7 — Public Communication

For citizens, media, and non‑technical stakeholders

Objectives

explain why PQC matters
explain why modernization is required
explain how Arizona is protecting data
maintain public trust
avoid misinformation

Artifacts

public FAQs
public briefings
press releases
public dashboards
educational materials

Tone

clear
simple
reassuring
non‑technical

23.8 — Messaging Themes for Each Audience

Audience	Primary Message
Executive Leadership	PQC is a statewide modernization imperative
Agencies	Hybrid deployment is mandatory and time‑bound
Vendors	Compliance is required and enforceable
Public Safety	Zero‑downtime transition with strict validation
Education	Cloud‑aligned, low‑disruption modernization
Critical Infrastructure	Long‑term, safety‑first modernization
Public	Arizona is proactively protecting long‑term data

23.9 — Change Management Strategy

Arizona must operate a structured change management program with:

1. Awareness

explain PQC
explain hybrid modes
explain timelines

2. Understanding

explain sector‑specific requirements
explain vendor obligations
explain validation processes

3. Adoption

deploy hybrid crypto
deploy PQC‑ready systems
deploy PQC‑only systems

4. Reinforcement

compliance reporting
validation
audits
incident response

Change management ensures that modernization is accepted, not resisted.

23.10 — Communication Cadence

Weekly

TWG technical updates
incident summaries

Monthly

SIG sector updates
vendor compliance updates

Quarterly

SPGC statewide updates
statewide dashboards
statewide risk register

Annually

statewide PQC modernization report
statewide roadmap update

23.11 — Communication Risks & Mitigations

Risk	Description	Mitigation
Vendor confusion	unclear requirements	vendor templates
Agency drift	inconsistent messaging	SPGC alignment
Public fear	misunderstanding PQC	clear public messaging
Sector misalignment	inconsistent timelines	SIG coordination
Technical misconfiguration	unclear guidance	TWG playbooks

23.12 — Why Communication Determines PQC Success

PQC migration fails when:

agencies misunderstand requirements
vendors misinterpret obligations
sectors drift
misinformation spreads
public trust erodes

PQC migration succeeds when:

communication is clear
messaging is consistent
governance is visible
vendors are aligned
the public understands the purpose

Communication is the social infrastructure of statewide PQC modernization.

Conclusion

This chapter defines the communication and change management framework Arizona must use to ensure that agencies, vendors, sectors, and the public understand PQC modernization, support it, and execute it consistently. Communication is the force multiplier that turns technical modernization into statewide transformation.

Chapter 24 — Training & Workforce Enablement: Building PQC Capability Across Arizona

Building PQC Capability Across Arizona — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that turns Arizona’s workforce into a PQC‑capable force — not just aware, not just trained, but operationally competent across hybrid deployment, PQC‑only transition, vendor evaluation, supply‑chain sovereignty, and statewide governance.

Technology cannot migrate itself. Vendors cannot enforce themselves. Governance cannot implement itself.

People do the work. This chapter ensures they can.

24.1 — Why Workforce Enablement Determines PQC Success

PQC migration is:

multi‑year
multi‑sector
multi‑vendor
high‑risk
high‑complexity

Without a trained workforce:

hybrid modes will be misconfigured
PQC‑only systems will break
identity outages will cascade
certificate chains will fail
OT/ICS systems will be disrupted
vendors will misrepresent readiness
supply‑chain sovereignty will collapse

With a trained workforce:

hybrid deployment is safe
PQC‑only transition is stable
vendors are held accountable
supply chains are verified
statewide compliance is real

Workforce capability is the operational backbone of PQC modernization.

24.2 — The Arizona PQC Workforce Enablement Framework (APQCWEF)

Arizona must operate a statewide workforce program with five pillars:

Foundational Training
Role‑Specific Training
Vendor‑Specific Training
Certification Pathways
Continuous Learning

Each pillar is mandatory.

24.3 — Pillar 1: Foundational Training

Every employee who touches a system must understand PQC basics

Audience

IT staff
security staff
procurement staff
leadership
cloud administrators
network teams
identity teams
OT/ICS operators

Curriculum

what PQC is
why hybrid modes are required
why PQC‑only transition must be staged
supply‑chain sovereignty
vendor obligations
statewide governance
HB2809 requirements

Outcome

Everyone understands the why, the what, and the stakes.

24.4 — Pillar 2: Role‑Specific Training

Deep, technical capability for practitioners

Arizona must train practitioners across six domains:

24.4.1 — Cryptography & Protocol Engineering

Skills:

hybrid KEM deployment
PQC‑only negotiation
certificate modernization
crypto‑agility architecture

24.4.2 — Identity & Access Management

Skills:

hybrid identity flows
PQC‑only identity flows
MFA signing modernization
trust store management

24.4.3 — Network & Transport Security

Skills:

hybrid TLS
hybrid VPN
PQC‑only TLS
PQC‑only VPN

24.4.4 — Cloud & Application Security

Skills:

cloud hybrid TLS
cloud PQC‑only TLS
PQC‑ready KMS
PQC‑ready API authentication

24.4.5 — OT/ICS Security

Skills:

hybrid gateways
PQC‑only gateways
firmware validation
telemetry encryption

24.4.6 — Procurement & Vendor Risk

Skills:

CBOM/SBOM analysis
supply‑chain sovereignty evaluation
PQC roadmap evaluation
contract enforcement

24.5 — Pillar 3: Vendor‑Specific Training

Arizona must train its workforce on the vendors they actually use

Required Vendor Training

cloud providers
identity providers
network vendors
VPN vendors
OT/ICS vendors
certificate authority vendors

Training Content

hybrid support
PQC‑only support
roadmap timelines
configuration requirements
validation procedures

Outcome

Arizona’s workforce knows exactly how each vendor implements PQC.

24.6 — Pillar 4: Certification Pathways

Formalizing PQC capability across the workforce

Arizona must create three statewide certifications:

24.6.1 — PQC Practitioner Certification

For:

IT staff
security staff

Skills:

hybrid basics
PQC basics
certificate basics

24.6.2 — PQC Implementation Certification

For:

engineers
architects

Skills:

hybrid deployment
PQC‑only deployment
vendor evaluation

24.6.3 — PQC Validation Certification

For:

TWG members
validation lab staff

Skills:

protocol testing
certificate chain validation
identity flow validation
OT/ICS gateway validation

24.7 — Pillar 5: Continuous Learning

PQC is not static — training must be ongoing

Quarterly

statewide workshops
vendor roadmap updates
hybrid/PQC‑only updates

Annually

statewide PQC summit
updated playbooks
updated test suites

Ongoing

TWG technical briefings
SIG sector briefings

24.8 — Workforce Capability Maturity Model (WCMM)

Arizona must measure workforce capability across five levels:

Level	Description	Capability
0	Unaware	No PQC knowledge
1	Aware	Basic understanding
2	Trained	Can follow playbooks
3	Competent	Can deploy hybrid
4	Proficient	Can validate PQC
5	Expert	Can architect PQC systems

Arizona must reach Level 4 statewide before PQC‑only transition.

24.9 — Workforce Enablement Risks & Mitigations

Risk	Description	Mitigation
Skill gaps	staff lack PQC knowledge	foundational training
Misconfiguration	hybrid modes misconfigured	role‑specific training
Vendor dependence	overreliance on vendors	vendor‑specific training
OT/ICS disruption	incorrect handling	specialized training
Cloud opacity	unclear cryptographic behavior	cloud training
Procurement gaps	vendors misrepresent readiness	procurement training

24.10 — Why Workforce Enablement Determines PQC Success

PQC migration fails when:

staff are untrained
hybrid modes are misconfigured
vendors are unchallenged
supply chains are unverified
identity systems break
OT/ICS systems are mishandled

PQC migration succeeds when:

staff are trained
hybrid modes are deployed correctly
vendors are held accountable
supply chains are sovereign
identity flows are stable
OT/ICS systems are protected

Workforce enablement is the human engine of statewide PQC modernization.

Conclusion

This chapter defines the training and workforce enablement program Arizona must operate to ensure that staff across all sectors have the skills, certifications, and ongoing support required to execute PQC migration safely and effectively. Workforce capability is the determining factor in the success of Arizona’s PQC modernization.

Chapter 25 — Budgeting & Funding Models: Financing Statewide PQC Modernization

Financing Statewide PQC Modernization — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that answers the question every policymaker, agency head, and budget office will eventually ask:

“How do we pay for all of this?”

PQC modernization is not a single project. It is a multi‑year, multi‑sector, multi‑vendor modernization program that touches:

every agency
every school district
every public safety system
every cloud integration
every OT/ICS environment
every vendor contract
every certificate
every identity flow

This chapter defines the funding models, budget structures, cost categories, and financial governance mechanisms Arizona must use to finance PQC modernization responsibly, sustainably, and transparently.

25.1 — Why PQC Requires a Dedicated Funding Model

PQC modernization is not:

a routine IT refresh
a discretionary upgrade
a “nice to have”
a one‑time capital project

It is:

a statutory requirement (HB2809)
a national security requirement
a federal alignment requirement
a multi‑year modernization program

Without dedicated funding:

agencies will delay
vendors will stall
critical infrastructure will fall behind
public safety systems will remain vulnerable
statewide compliance will fail

Funding is the fuel of statewide PQC modernization.

25.2 — The Arizona PQC Funding Framework (APQCFF)

Arizona must operate a funding framework with five funding streams:

Statewide PQC Modernization Fund
Agency Modernization Budgets
Sector‑Specific Grants
Vendor Cost‑Shifting Mechanisms
Federal Funding Alignment

Each stream plays a different role.

25.3 — Funding Stream 1: Statewide PQC Modernization Fund

The core funding mechanism

Arizona must establish a centralized statewide fund to support:

governance (SPGC, SIGs, TWGs)
statewide validation lab
statewide monitoring infrastructure
statewide certificate authority modernization
statewide training programs
statewide procurement modernization
statewide risk management

This fund ensures:

consistency
equity
statewide alignment
economies of scale

25.4 — Funding Stream 2: Agency Modernization Budgets

Agencies must fund their own modernization work

Agencies must budget for:

hybrid TLS deployment
hybrid VPN deployment
identity modernization
certificate lifecycle modernization
cloud integration updates
application modernization
workforce training
vendor compliance

Agencies cannot rely solely on statewide funding.

25.5 — Funding Stream 3: Sector‑Specific Grants

Education, public safety, and critical infrastructure require tailored support

Education

K–12 cybersecurity grants
higher‑ed modernization grants
cloud modernization grants

Public Safety

CJIS‑aligned modernization grants
radio/dispatch modernization grants
secure communications modernization grants

Critical Infrastructure

OT/ICS modernization grants
SCADA gateway modernization grants
firmware signing modernization grants

These sectors have unique constraints and require targeted funding.

25.6 — Funding Stream 4: Vendor Cost‑Shifting Mechanisms

Vendors must bear part of the cost

Arizona must require vendors to:

update cryptographic libraries
update firmware
update cloud integrations
update identity integrations
provide CBOM/SBOM
provide supply‑chain sovereignty documentation
pass hybrid and PQC‑only validation

These costs must be vendor‑absorbed, not state‑absorbed.

Mechanisms

contract clauses
renewal conditions
RFP requirements
vendor readiness scoring

Vendors must modernize at their own expense.

25.7 — Funding Stream 5: Federal Funding Alignment

Arizona must leverage federal programs

Federal funding sources include:

CISA cybersecurity grants
DHS critical infrastructure grants
DOE grid modernization grants
DOJ public safety modernization grants
NSF research grants
federal PQC transition support programs

Arizona must align PQC modernization with federal funding cycles.

25.8 — Cost Categories for PQC Modernization

Arizona must budget across eight cost categories:

Governance & Oversight
Hybrid Deployment
PQC‑Only Transition
Certificate Authority Modernization
Identity Modernization
Cloud Modernization
OT/ICS Modernization
Training & Workforce Enablement

Each category has predictable cost drivers.

25.9 — Cost Category 1: Governance & Oversight

Costs include:

SPGC operations
SIG operations
TWG operations
statewide dashboards
statewide risk register
statewide reporting

These costs are centralized and shared.

25.10 — Cost Category 2: Hybrid Deployment

Costs include:

hybrid TLS deployment
hybrid VPN deployment
hybrid identity flows
hybrid certificates
hybrid cloud integrations
hybrid OT/ICS gateways

Hybrid deployment is the largest cost category in 2027–2028.

25.11 — Cost Category 3: PQC‑Only Transition

Costs include:

PQC‑only certificates
PQC‑only TLS
PQC‑only VPN
PQC‑only identity flows
PQC‑only cloud integrations
PQC‑only OT/ICS gateways

These costs peak in 2029–2030.

25.12 — Cost Category 4: Certificate Authority Modernization

Costs include:

hybrid CA hierarchy
PQC‑only CA hierarchy
OCSP/CRL modernization
offline CA capability
certificate lifecycle tooling

This is a statewide shared cost.

25.13 — Cost Category 5: Identity Modernization

Costs include:

hybrid identity flows
PQC‑only identity flows
MFA modernization
trust store modernization
SAML/OIDC modernization

Identity modernization is high‑risk and high‑impact.

25.14 — Cost Category 6: Cloud Modernization

Costs include:

hybrid cloud TLS
PQC‑only cloud TLS
hybrid/PQC‑only identity
hybrid/PQC‑only API authentication
PQC‑ready KMS

Cloud modernization is vendor‑dependent and must be cost‑shifted where possible.

25.15 — Cost Category 7: OT/ICS Modernization

Costs include:

hybrid gateways
PQC‑only gateways
firmware updates
hardware replacement
segmentation
compensating controls

OT/ICS modernization is the longest and most expensive category.

25.16 — Cost Category 8: Training & Workforce Enablement

Costs include:

foundational training
role‑specific training
vendor‑specific training
certification programs
statewide PQC summit

Training is a recurring annual cost.

25.17 — Funding Governance

SPGC

approves statewide budget
allocates statewide funds
enforces vendor cost‑shifting

SIGs

manage sector budgets
report sector needs
coordinate sector grants

TWGs

estimate technical costs
validate vendor cost‑shifting
validate modernization costs

25.18 — Budget Risks & Mitigations

Risk	Description	Mitigation
Underfunding	agencies lack resources	statewide fund
Vendor cost‑shifting failure	vendors push costs to state	procurement enforcement
Cloud vendor lag	cloud modernization delayed	federal alignment
OT/ICS cost overruns	long hardware cycles	multi‑year funding
Workforce gaps	insufficient training	certification programs

25.19 — Why Budgeting Determines PQC Success

PQC migration fails when:

funding is insufficient
funding is inconsistent
funding is misaligned
vendors shift costs to the state
sectors cannot modernize
OT/ICS modernization stalls

PQC migration succeeds when:

funding is centralized
funding is predictable
funding is multi‑year
vendors bear their share
sectors receive targeted support
critical infrastructure receives long‑term funding

Budgeting is the financial backbone of statewide PQC modernization.

Conclusion

This chapter defines the funding models, cost categories, and financial governance mechanisms Arizona must use to finance PQC modernization responsibly and sustainably. PQC modernization is a multi‑year investment in statewide security, sovereignty, and resilience — and it requires a structured, disciplined, and enforceable funding model.

Chapter 26 — Procurement Templates & Contract Language: Enforceable Requirements for Vendors

Enforceable Requirements for Vendors — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that gives Arizona teeth.

Everything up to this point — governance, validation, hybrid deployment, PQC‑only transition, supply‑chain sovereignty — depends on one thing:

Vendors must comply.

Not voluntarily. Not aspirationally. Not “roadmap‑pending.” Not “we’re working on it.”

Contractually. Enforceably. Legally.

This chapter provides the exact procurement templates, contract clauses, and enforcement mechanisms Arizona must use to ensure that every vendor — cloud, software, hardware, OT/ICS, integrator, MSP, MSSP — meets PQC requirements.

This is the chapter procurement officers will use every day for the next decade.

26.1 — Why Procurement Is the Enforcement Arm of PQC Modernization

PQC migration fails when:

vendors delay
vendors misrepresent readiness
vendors hide supply‑chain dependencies
vendors ship outdated crypto
vendors refuse to provide CBOM/SBOM
vendors rely on foreign cryptography
vendors push costs onto the state

Procurement is the only mechanism that forces vendors to:

modernize
document
validate
comply
remediate
remain sovereign

Procurement is the lever that moves the entire vendor ecosystem.

26.2 — The Arizona PQC Procurement Framework (APQCPF)

Arizona must operate a procurement framework with five enforceable components:

Mandatory PQC Requirements
Mandatory Hybrid Requirements
Mandatory Documentation Requirements
Mandatory Validation Requirements
Mandatory Supply‑Chain Sovereignty Requirements

Each component is non‑negotiable.

26.3 — Mandatory PQC Requirements (Contract Language)

Clause: PQC Algorithm Support

Vendor must support:

ML‑KEM for key establishment
ML‑DSA or SLH‑DSA for signatures
PQC‑only operation by 2030

Failure to support these algorithms constitutes material breach.

Clause: PQC‑Only Readiness

Vendor must provide:

PQC‑only configuration
PQC‑only documentation
PQC‑only validation results

Vendor must be PQC‑only ready no later than 2029.

26.4 — Mandatory Hybrid Requirements (Contract Language)

Clause: Hybrid Mode Support

Vendor must support:

ML‑KEM + classical hybrid KEM
ML‑DSA/SLH‑DSA + classical hybrid signatures
hybrid TLS 1.3
hybrid VPN
hybrid identity flows

Hybrid support must be available at contract signing.

Clause: Hybrid Mode Documentation

Vendor must provide:

hybrid configuration guides
hybrid compatibility matrices
hybrid fallback behavior documentation

Failure to provide documentation is grounds for contract suspension.

26.5 — Mandatory Documentation Requirements (Contract Language)

Clause: CBOM/SBOM

Vendor must provide:

complete cryptographic bill of materials (CBOM)
complete software bill of materials (SBOM)
updated CBOM/SBOM annually
updated CBOM/SBOM after any major release

Failure to provide CBOM/SBOM is grounds for disqualification.

Clause: Supply‑Chain Documentation

Vendor must provide:

firmware origin documentation
hardware origin documentation
cryptographic module origin documentation
legal jurisdiction documentation

Foreign cryptographic components are prohibited.

Clause: PQC Roadmap

Vendor must provide:

hybrid support timeline
PQC‑only support timeline
firmware update timeline
cloud integration timeline

Roadmap must be updated annually.

26.6 — Mandatory Validation Requirements (Contract Language)

Clause: Hybrid Validation

Vendor must pass:

statewide hybrid TLS test suite
statewide hybrid VPN test suite
statewide hybrid identity test suite
statewide hybrid certificate test suite

Failure to pass validation prohibits deployment.

Clause: PQC‑Only Validation

Vendor must pass:

statewide PQC‑only TLS test suite
statewide PQC‑only VPN test suite
statewide PQC‑only identity test suite
statewide PQC‑only certificate test suite

Failure to pass PQC‑only validation prohibits renewal.

26.7 — Mandatory Supply‑Chain Sovereignty Requirements

Clause: U.S.‑Developed Cryptography

Vendor must use:

U.S.‑developed cryptographic modules
U.S.‑developed firmware
U.S.‑controlled hardware

Foreign cryptographic components are prohibited.

Clause: No Foreign Legal Exposure

Vendor must attest that:

no foreign government can compel access
no foreign jurisdiction applies
no foreign cryptographic dependencies exist

Violation constitutes immediate contract termination.

26.8 — Enforcement Mechanisms

Arizona must enforce compliance through:

1. Contractual Enforcement

mandatory clauses
mandatory timelines
mandatory validation

2. Renewal Enforcement

no renewal without hybrid support
no renewal without PQC‑only readiness
no renewal without CBOM/SBOM

3. Procurement Disqualification

vendors who fail validation
vendors who fail sovereignty requirements
vendors who misrepresent readiness

4. Vendor Freeze Mechanisms

block updates
block integrations
block deployments

5. SPGC Enforcement

statewide authority
emergency powers
vendor suspension

26.9 — Procurement Templates

Arizona must maintain templates for:

RFP language
contract clauses
vendor readiness scoring
CBOM/SBOM submission
supply‑chain sovereignty attestation
hybrid validation requirements
PQC‑only validation requirements

These templates must be updated annually.

26.10 — Vendor Readiness Scoring Model

Vendors must be scored across:

Category	Weight
Hybrid Support	25%
PQC‑Only Readiness	25%
Supply‑Chain Sovereignty	20%
Documentation Quality	15%
Validation Results	10%
Roadmap Credibility	5%

Vendors below 80% are disqualified.

26.11 — Procurement Risks & Mitigations

Risk	Description	Mitigation
Vendor delay	roadmap slips	contractual penalties
Vendor misrepresentation	inaccurate claims	validation + audits
Supply‑chain opacity	hidden foreign components	CBOM/SBOM + sovereignty checks
Cloud vendor lag	unclear cryptographic behavior	contractual requirements
OT/ICS vendor constraints	long hardware cycles	transitional controls

26.12 — Why Procurement Determines PQC Success

PQC migration fails when:

vendors are unregulated
contracts are vague
requirements are optional
validation is not enforced
supply chains are opaque

PQC migration succeeds when:

requirements are contractual
validation is mandatory
sovereignty is enforced
vendors are accountable
procurement has authority

Procurement is the legal enforcement engine of statewide PQC modernization.

Conclusion

This chapter provides the procurement templates, contract clauses, and enforcement mechanisms Arizona must use to ensure that vendors comply with hybrid and PQC‑only requirements, supply‑chain sovereignty mandates, and statewide validation standards. Procurement is the mechanism that forces the vendor ecosystem to modernize.

Chapter 27 — Reporting & Metrics: Statewide Dashboards, KPIs, and Compliance Tracking

Statewide Dashboards, KPIs, and Compliance Tracking — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that turns Arizona’s PQC modernization into something measurable, visible, and auditable.

Governance gives authority. Procurement gives enforcement. Validation gives correctness. Monitoring gives visibility.

Reporting gives proof.

This chapter defines the statewide reporting architecture, KPIs, dashboards, and compliance mechanisms Arizona must use to track progress, enforce accountability, and maintain transparency across agencies, sectors, vendors, and critical infrastructure.

This is the chapter policymakers will read first and vendors will fear most.

27.1 — Why Reporting & Metrics Matter

PQC modernization is:

multi‑year
multi‑sector
multi‑vendor
high‑risk
high‑visibility

Without reporting:

agencies drift
vendors stall
sectors misalign
compliance collapses
policymakers lose visibility
the public loses trust

With reporting:

progress is measurable
compliance is enforceable
risks are visible
vendors are accountable
statewide alignment is maintained

Reporting is the accountability engine of statewide PQC modernization.

27.2 — The Arizona PQC Reporting Framework (APQCRF)

Arizona must operate a reporting framework with four reporting layers:

Local Reporting — agencies, schools, public safety, OT/ICS operators
Sector Reporting — SIG‑level consolidation
Statewide Reporting — SPGC dashboards and compliance reports
Public Reporting — transparency dashboards and summaries

Each layer feeds the next.

27.3 — Layer 1: Local Reporting

Where data is generated

Local entities must report:

1. Hybrid Deployment Status

hybrid TLS
hybrid VPN
hybrid identity
hybrid certificates
hybrid cloud integrations
hybrid OT/ICS gateways

2. PQC‑Only Readiness

PQC‑only TLS
PQC‑only VPN
PQC‑only identity
PQC‑only certificates
PQC‑only cloud integrations
PQC‑only OT/ICS gateways

3. Vendor Compliance

CBOM/SBOM submissions
supply‑chain sovereignty documentation
hybrid validation results
PQC‑only validation results

4. Workforce Capability

training completion
certification levels
staffing gaps

Local reporting is monthly.

27.4 — Layer 2: Sector Reporting (SIGs)

Where reporting becomes actionable

SIGs consolidate local reports into sector‑level dashboards.

Sector Dashboards Include

hybrid deployment percentage
PQC‑only readiness percentage
vendor compliance status
sector risk map
sector incident summaries
sector workforce capability

Sector KPIs

% hybrid TLS deployed
% hybrid VPN deployed
% hybrid identity deployed
% PQC‑ready certificates
% PQC‑ready cloud integrations
% PQC‑ready OT/ICS gateways
% vendor compliance
% workforce trained

Sector reporting is quarterly.

27.5 — Layer 3: Statewide Reporting (SPGC)

Where reporting becomes governance

SPGC maintains the statewide PQC dashboard, which includes:

Statewide KPIs

statewide hybrid deployment percentage
statewide PQC‑only readiness percentage
statewide vendor compliance percentage
statewide supply‑chain sovereignty score
statewide risk index
statewide incident index
statewide workforce capability index

Statewide Compliance Metrics

% agencies compliant with HB2809
% vendors compliant with PQC requirements
% sectors aligned with statewide roadmap
% systems validated by TWGs

Statewide Risk Metrics

number of hybrid failures
number of PQC‑only failures
number of vendor regressions
number of supply‑chain sovereignty violations

Statewide reporting is quarterly and annual.

27.6 — Layer 4: Public Reporting

Where reporting becomes trust

Arizona must publish:

Public Dashboards

statewide hybrid deployment progress
statewide PQC‑only readiness
statewide vendor compliance summary
statewide risk posture (non‑sensitive)

Public Reports

annual PQC modernization report
annual supply‑chain sovereignty report
annual vendor compliance report

Public reporting builds trust, transparency, and legitimacy.

27.7 — Key Performance Indicators (KPIs)

Arizona must track KPIs across six domains:

27.7.1 — Cryptographic KPIs

% hybrid TLS deployed
% PQC‑only TLS deployed
% hybrid VPN deployed
% PQC‑only VPN deployed
% hybrid identity flows
% PQC‑only identity flows

27.7.2 — Certificate KPIs

% hybrid certificates issued
% PQC‑only certificates issued
% certificate chain validation success
% OCSP/CRL uptime

27.7.3 — Cloud KPIs

% hybrid cloud integrations
% PQC‑only cloud integrations
% cloud identity PQC readiness
% cloud KMS PQC readiness

27.7.4 — OT/ICS KPIs

% hybrid gateways deployed
% PQC‑only gateways deployed
% firmware PQC readiness
% hardware PQC readiness

27.7.5 — Vendor KPIs

% vendors with CBOM/SBOM
% vendors with PQC roadmaps
% vendors passing hybrid validation
% vendors passing PQC‑only validation
% vendors meeting sovereignty requirements

27.7.6 — Workforce KPIs

% staff trained
% staff certified
% TWG‑qualified staff
% sector workforce at Level 4 capability

27.8 — Compliance Tracking

Arizona must track compliance across:

1. Agencies

hybrid deployment
PQC‑only readiness
reporting completeness
validation results

2. Vendors

documentation
validation
sovereignty
roadmap adherence

3. Sectors

roadmap alignment
risk posture
incident response

4. Statewide

HB2809 compliance
federal alignment
supply‑chain sovereignty

Compliance is enforced by SPGC.

27.9 — Reporting Governance

TWGs

validate technical data
publish validation results
maintain test suites

SIGs

consolidate sector data
maintain sector dashboards
escalate sector risks

SPGC

maintain statewide dashboard
enforce compliance
publish statewide reports

27.10 — Reporting Risks & Mitigations

Risk	Description	Mitigation
Incomplete reporting	agencies fail to report	SPGC enforcement
Vendor misreporting	inaccurate documentation	validation + audits
Sector misalignment	inconsistent metrics	standardized KPIs
Cloud opacity	unclear cryptographic behavior	cloud audits
OT/ICS gaps	limited telemetry	hybrid gateways

27.11 — Why Reporting Determines PQC Success

PQC migration fails when:

progress is invisible
compliance is unenforced
vendors misrepresent readiness
risks go unreported
sectors drift

PQC migration succeeds when:

reporting is rigorous
metrics are standardized
dashboards are accurate
compliance is enforced
governance is informed

Reporting is the visibility layer of statewide PQC modernization.

Conclusion

This chapter defines the reporting architecture, KPIs, dashboards, and compliance mechanisms Arizona must use to track progress, enforce accountability, and maintain transparency across all sectors and vendors. Reporting is the mechanism that ensures statewide PQC modernization is measurable, auditable, and governable.

Chapter 28 — Legal & Regulatory Alignment: HB2809, Federal Mandates, and Cross‑Jurisdictional Requirements

HB2809, Federal Mandates, and Cross‑Jurisdictional Requirements — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that locks Arizona’s PQC modernization into law, policy, and regulatory authority — the chapter that ensures the entire statewide program is not just technically correct, but legally defensible, federally aligned, and jurisdictionally interoperable.

PQC modernization is not optional. It is not discretionary. It is not “best practice.”

It is statutory, federal, and cross‑jurisdictional.

This chapter defines the legal scaffolding that ensures Arizona’s PQC posture is enforceable, sovereign, and aligned with national security requirements.

28.1 — Why Legal & Regulatory Alignment Matters

PQC modernization touches:

state law
federal mandates
sector‑specific regulations
cross‑border data flows
supply‑chain sovereignty
procurement law
public safety requirements
critical infrastructure regulations

Without legal alignment:

agencies cannot enforce compliance
vendors cannot be held accountable
cross‑jurisdictional systems break
federal funding is jeopardized
supply‑chain sovereignty collapses

Legal alignment is the authority layer of statewide PQC modernization.

28.2 — HB2809: Arizona’s PQC Statutory Mandate

HB2809 is the legal foundation of Arizona’s PQC modernization.

It requires:

1. Statewide Cryptographic Inventory

All agencies must inventory:

cryptographic systems
certificates
identity flows
VPN tunnels
cloud integrations
OT/ICS systems

2. Hybrid Deployment

Agencies must deploy:

hybrid TLS
hybrid VPN
hybrid identity
hybrid certificates

3. PQC‑Only Transition

Agencies must transition to:

PQC‑only TLS
PQC‑only VPN
PQC‑only identity
PQC‑only certificates

4. Vendor Compliance

Vendors must provide:

CBOM/SBOM
supply‑chain sovereignty documentation
PQC roadmaps
hybrid/PQC‑only validation

5. Governance

Arizona must operate:

SPGC
SIGs
TWGs

HB2809 is the legal engine of statewide PQC modernization.

28.3 — Federal Mandates & Alignment Requirements

Arizona must align with federal requirements across:

28.3.1 — NIST PQC Standards

Arizona must adopt:

ML‑KEM
ML‑DSA
SLH‑DSA

These are the federal cryptographic standards.

28.3.2 — CISA PQC Roadmap

Arizona must align with:

hybrid deployment guidance
PQC‑only transition guidance
federal risk models
federal supply‑chain requirements

28.3.3 — OMB & Federal Agency Requirements

Federal agencies must:

inventory cryptography
deploy hybrid crypto
transition to PQC

Arizona must align with these requirements for:

federal data
federal integrations
federal funding

28.3.4 — CJIS Requirements (Public Safety)

Public safety systems must align with:

CJIS cryptographic requirements
CJIS identity requirements
CJIS network requirements

CJIS will eventually mandate hybrid → PQC‑only.

28.3.5 — DOE, DHS, and Sector‑Specific Mandates

Critical infrastructure must align with:

DOE grid modernization
DHS critical infrastructure security
NERC CIP (where applicable)

These mandates will incorporate PQC requirements.

28.4 — Cross‑Jurisdictional Requirements

Arizona must ensure PQC alignment across:

1. Interstate Data Sharing

public safety
education
health
transportation

2. Federal‑State Integrations

cloud identity
federal APIs
federal data exchanges

3. Multi‑State Critical Infrastructure

energy
water
transportation
telecommunications

Cross‑jurisdictional systems must support:

hybrid crypto
PQC‑only crypto
supply‑chain sovereignty

28.5 — Supply‑Chain Sovereignty Requirements

Arizona must legally require:

1. U.S.‑Developed Cryptography

no foreign cryptographic modules
no foreign firmware
no foreign legal exposure

2. CBOM/SBOM

cryptographic bill of materials
software bill of materials

3. Legal Jurisdiction Documentation

no foreign data access laws
no foreign ownership structures

4. Vendor Attestation

Vendors must legally attest to:

cryptographic origin
firmware origin
hardware origin
supply‑chain sovereignty

Violations must trigger:

contract termination
vendor disqualification
SPGC enforcement

28.6 — Regulatory Alignment by Sector

28.6.1 — State Agencies

Must align with:

HB2809
statewide PQC roadmap
statewide validation requirements
statewide procurement requirements

28.6.2 — Education

Must align with:

FERPA
statewide PQC requirements
cloud provider PQC requirements

28.6.3 — Public Safety

Must align with:

CJIS
statewide PQC requirements
radio/dispatch modernization requirements

28.6.4 — Critical Infrastructure

Must align with:

DOE
DHS
NERC CIP (where applicable)
statewide PQC requirements

28.7 — Legal Enforcement Mechanisms

Arizona must enforce compliance through:

1. Statutory Enforcement

HB2809 mandates:

inventory
hybrid deployment
PQC‑only transition

2. Contractual Enforcement

Procurement mandates:

hybrid support
PQC‑only support
CBOM/SBOM
sovereignty documentation

3. Renewal Enforcement

No renewal without:

hybrid support
PQC‑only readiness
sovereignty compliance

4. SPGC Enforcement

SPGC may:

suspend vendors
mandate rollback
mandate remediation
escalate to state leadership

28.8 — Legal Risks & Mitigations

Risk	Description	Mitigation
Vendor non‑compliance	vendors fail to meet requirements	procurement enforcement
Supply‑chain opacity	hidden foreign components	CBOM/SBOM + sovereignty checks
Cross‑jurisdictional misalignment	interstate/federal incompatibility	hybrid support
Cloud vendor lag	unclear cryptographic behavior	contractual requirements
Sector misalignment	inconsistent regulatory requirements	SIG coordination

28.9 — Why Legal Alignment Determines PQC Success

PQC migration fails when:

requirements are optional
vendors are unregulated
supply chains are opaque
federal alignment is missing
cross‑jurisdictional systems break

PQC migration succeeds when:

requirements are statutory
vendors are contractually bound
sovereignty is enforced
federal alignment is maintained
cross‑jurisdictional systems interoperate

Legal alignment is the authority layer of statewide PQC modernization.

Conclusion

This chapter defines the legal, regulatory, and cross‑jurisdictional framework Arizona must operate to ensure that PQC modernization is enforceable, sovereign, federally aligned, and legally defensible. HB2809 provides the statutory foundation; procurement provides enforcement; SPGC provides authority.

Chapter 29 — Cross‑Sector Coordination: Aligning Agencies, Education, Public Safety, and Critical Infrastructure

Aligning Agencies, Education, Public Safety, and Critical Infrastructure — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that ensures Arizona does not become four separate PQC migrations happening in parallel — each with its own timelines, vendors, risks, and failures.

Cross‑sector coordination is what turns:

170+ state agencies
200+ school districts
400+ public safety organizations
100+ critical infrastructure operators

…into a single, coherent statewide modernization effort.

Without cross‑sector coordination:

agencies drift
education lags
public safety breaks
critical infrastructure resists
cloud integrations fragment
vendors exploit inconsistencies
statewide compliance collapses

With cross‑sector coordination:

timelines align
vendors comply
risks are shared
failures are contained
procurement is unified
modernization is coherent

This chapter defines the coordination architecture that keeps Arizona’s PQC modernization synchronized across all sectors.

29.1 — Why Cross‑Sector Coordination Is Mandatory

PQC modernization is not a siloed effort. Every sector depends on every other sector:

Agencies depend on cloud and identity providers.
Education depends on cloud identity and SIS/LMS vendors.
Public safety depends on CJIS, dispatch, and radio vendors.
Critical infrastructure depends on OT/ICS vendors and federal regulators.

If one sector falls behind, everyone is affected.

Cross‑sector coordination is the synchronization layer of statewide PQC modernization.

29.2 — The Arizona Cross‑Sector Coordination Framework (ACSCF)

Arizona must operate a coordination framework with four pillars:

Shared Timelines
Shared Vendors
Shared Risks
Shared Validation

Each pillar ensures statewide alignment.

29.3 — Pillar 1: Shared Timelines

Arizona must maintain one statewide timeline (Chapter 16), with sector‑specific adaptations (Chapter 17).

Shared Milestones

2026: Inventory + governance
2027: Hybrid deployment
2028: Hybrid stabilization
2029: PQC‑only preparation
2030: PQC‑only transition

Sector‑Specific Adjustments

Education: cloud‑aligned
Public safety: CJIS‑aligned
Critical infrastructure: extended to 2035

Shared timelines prevent fragmentation.

29.4 — Pillar 2: Shared Vendors

Most sectors use the same vendors, even if they don’t realize it.

Shared Cloud Vendors

Microsoft
Google
AWS

Shared Identity Vendors

Azure AD
Okta
Google Identity

Shared Network Vendors

Cisco
Palo Alto
Fortinet

Shared OT/ICS Vendors

Siemens
Schneider Electric
Rockwell Automation

Shared Certificate Vendors

Entrust
DigiCert
Sectigo

Shared vendors require shared procurement, shared validation, and shared enforcement.

29.5 — Pillar 3: Shared Risks

Sectors share common risks, including:

1. Vendor Delays

If a cloud provider slips, everyone slips.

2. Identity Fragility

If identity breaks, everyone breaks.

3. Certificate Chain Failures

If certificate chains fail, everyone fails.

4. Supply‑Chain Sovereignty

If one vendor violates sovereignty, everyone is exposed.

5. Cloud Regression

If a cloud provider regresses to classical crypto, everyone regresses.

Shared risks require shared mitigation.

29.6 — Pillar 4: Shared Validation

Arizona must operate one statewide validation lab (Chapter 19) that:

tests hybrid TLS
tests hybrid VPN
tests hybrid identity
tests PQC‑only TLS
tests PQC‑only VPN
tests PQC‑only identity
tests cloud integrations
tests OT/ICS gateways

Shared validation ensures:

consistency
interoperability
vendor accountability

29.7 — Sector‑to‑Sector Coordination Requirements

Each sector must coordinate with every other sector in specific ways.

29.7.1 — Agencies ↔ Education

Shared dependencies:

cloud identity
SIS/LMS integrations
statewide CA hierarchy

Coordination requirements:

shared identity validation
shared cloud validation
shared certificate policies

29.7.2 — Agencies ↔ Public Safety

Shared dependencies:

CJIS integrations
statewide networks
statewide identity

Coordination requirements:

hybrid VPN alignment
identity modernization alignment
certificate chain alignment

29.7.3 — Agencies ↔ Critical Infrastructure

Shared dependencies:

OT/ICS gateways
SCADA integrations
statewide CA hierarchy

Coordination requirements:

hybrid gateway validation
PQC‑only gateway validation
firmware signing alignment

29.7.4 — Education ↔ Public Safety

Shared dependencies:

cloud identity
statewide networks

Coordination requirements:

identity modernization
cloud PQC alignment

29.7.5 — Education ↔ Critical Infrastructure

Shared dependencies:

campus OT/ICS (HVAC, access control)
cloud identity

Coordination requirements:

hybrid gateway deployment
PQC‑only gateway planning

29.7.6 — Public Safety ↔ Critical Infrastructure

Shared dependencies:

dispatch → utility coordination
emergency response systems
SCADA telemetry

Coordination requirements:

hybrid gateway alignment
PQC‑only gateway alignment
firmware signing alignment

29.8 — Cross‑Sector Governance

Cross‑sector coordination is enforced through:

SPGC

statewide authority
statewide enforcement
statewide sequencing

SIGs

sector alignment
sector reporting
sector risk escalation

TWGs

technical alignment
shared validation
shared standards

Governance ensures sectors move together, not separately.

29.9 — Cross‑Sector Dashboards

Arizona must maintain dashboards showing:

Cross‑Sector Hybrid Deployment

TLS
VPN
identity
certificates
cloud
OT/ICS

Cross‑Sector PQC‑Only Readiness

TLS
VPN
identity
certificates
cloud
OT/ICS

Cross‑Sector Vendor Compliance

hybrid validation
PQC‑only validation
sovereignty compliance

Cross‑Sector Risk Map

shared risks
sector‑specific risks
statewide risks

29.10 — Cross‑Sector Incident Response

When one sector fails, others may follow.

Arizona must operate cross‑sector IR playbooks for:

hybrid TLS failure
PQC‑only TLS failure
identity failure
VPN failure
cloud regression
OT/ICS gateway failure
certificate chain failure

Cross‑sector IR prevents cascading failures.

29.11 — Cross‑Sector Risks & Mitigations

Risk	Description	Mitigation
Sector drift	sectors move at different speeds	SPGC enforcement
Vendor fragmentation	inconsistent vendor behavior	shared procurement
Cloud regression	cloud provider breaks compatibility	shared validation
Identity fragility	SSO/MFA failures cascade	shared identity modernization
Certificate chain mismatch	inconsistent CA hierarchies	statewide CA governance
OT/ICS constraints	long hardware cycles	shared transitional controls

29.12 — Why Cross‑Sector Coordination Determines PQC Success

PQC migration fails when:

sectors operate independently
vendors exploit fragmentation
cloud providers regress
identity systems break
certificate chains diverge
OT/ICS systems lag

PQC migration succeeds when:

sectors move together
vendors face unified requirements
cloud providers face unified pressure
identity flows are consistent
certificate chains are unified
OT/ICS modernization is coordinated

Cross‑sector coordination is the synchronization engine of statewide PQC modernization.

Conclusion

This chapter defines the cross‑sector coordination architecture Arizona must operate to ensure that agencies, education, public safety, and critical infrastructure modernize together — not separately. Coordination is the mechanism that prevents fragmentation, enforces consistency, and ensures statewide PQC success.

Chapter 30 — Stakeholder Engagement: Aligning Leadership, Practitioners, Vendors, and the Public

Aligning Leadership, Practitioners, Vendors, and the Public — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that ensures every human being involved in Arizona’s PQC modernization — from the Governor to the help‑desk technician, from the superintendent to the sheriff, from the utility operator to the cloud vendor — understands their role, their responsibilities, and the stakes.

Technology alone cannot deliver PQC modernization. Governance alone cannot enforce it. Procurement alone cannot compel it.

People must align. This chapter ensures they do.

30.1 — Why Stakeholder Engagement Determines PQC Success

PQC modernization touches:

leadership
practitioners
vendors
regulators
educators
public safety
critical infrastructure
the public

If any group is misaligned:

timelines drift
vendors stall
sectors misinterpret requirements
identity systems break
certificate chains diverge
OT/ICS systems resist modernization
public trust erodes

Stakeholder engagement is the human coordination layer of statewide PQC modernization.

30.2 — The Arizona Stakeholder Engagement Framework (ASEF)

Arizona must operate a stakeholder engagement framework with four engagement domains:

Leadership Engagement
Practitioner Engagement
Vendor Engagement
Public Engagement

Each domain has its own messaging, cadence, and responsibilities.

30.3 — Leadership Engagement

Ensuring executive alignment and sustained support

Audience

Governor’s Office
Legislature
agency directors
CIOs/CISOs
public safety leadership
critical infrastructure executives

Objectives

maintain political support
secure funding
enforce compliance
align statewide priorities
communicate risks and progress

Engagement Mechanisms

quarterly SPGC briefings
annual statewide PQC report
executive dashboards
legislative updates

Leadership Messaging Themes

PQC is a statewide modernization imperative
hybrid deployment is mandatory
PQC‑only transition is unavoidable
supply‑chain sovereignty is non‑negotiable

Leadership engagement ensures top‑down alignment.

30.4 — Practitioner Engagement

Ensuring the people doing the work understand the work

Audience

engineers
architects
analysts
identity teams
network teams
cloud teams
OT/ICS operators
procurement officers

Objectives

ensure technical understanding
ensure correct implementation
ensure correct validation
ensure correct incident response
ensure correct procurement enforcement

Engagement Mechanisms

TWG technical briefings
implementation playbooks
validation reports
troubleshooting guides
training and certification programs

Practitioner Messaging Themes

hybrid modes must be deployed correctly
PQC‑only transition must be staged
identity is fragile
certificate chains must be consistent
OT/ICS requires caution

Practitioner engagement ensures bottom‑up capability.

30.5 — Vendor Engagement

Ensuring vendors comply, modernize, and remain sovereign

Audience

cloud providers
software vendors
hardware vendors
OT/ICS vendors
integrators
MSPs/MSSPs

Objectives

enforce hybrid support
enforce PQC‑only readiness
enforce CBOM/SBOM
enforce supply‑chain sovereignty
enforce validation requirements

Engagement Mechanisms

procurement templates
contract clauses
vendor readiness scorecards
validation lab results
roadmap reviews

Vendor Messaging Themes

compliance is mandatory
sovereignty is required
validation is enforceable
timelines are non‑negotiable

Vendor engagement ensures ecosystem alignment.

30.6 — Public Engagement

Ensuring trust, clarity, and transparency

Audience

citizens
media
advocacy groups
local governments
school boards

Objectives

explain why PQC matters
explain how Arizona is protecting long‑term data
prevent misinformation
maintain public trust
demonstrate statewide progress

Engagement Mechanisms

public dashboards
public FAQs
press releases
educational materials
annual public report

Public Messaging Themes

PQC protects long‑term data
modernization is proactive
modernization is statewide
modernization is safe

Public engagement ensures social legitimacy.

30.7 — Stakeholder Mapping

Arizona must maintain a stakeholder map identifying:

who is affected
who has authority
who has influence
who has operational responsibility
who has vendor relationships
who has regulatory obligations

Stakeholders must be mapped across:

agencies
education
public safety
critical infrastructure
cloud providers
OT/ICS vendors
integrators
the public

Stakeholder mapping ensures no group is overlooked.

30.8 — Engagement Cadence

Weekly

TWG technical updates
incident summaries

Monthly

SIG sector updates
vendor roadmap updates

Quarterly

SPGC statewide updates
statewide dashboards
statewide risk register

Annually

statewide PQC modernization report
statewide roadmap update
statewide PQC summit

Engagement cadence ensures predictability.

30.9 — Stakeholder Engagement Risks & Mitigations

Risk	Description	Mitigation
Leadership turnover	loss of executive alignment	SPGC continuity
Practitioner fatigue	complexity overload	training + playbooks
Vendor resistance	cost or roadmap delays	procurement enforcement
Public misunderstanding	fear or misinformation	clear public messaging
Sector misalignment	inconsistent priorities	SIG coordination

30.10 — Why Stakeholder Engagement Determines PQC Success

PQC migration fails when:

leadership is disengaged
practitioners are confused
vendors resist
sectors drift
the public misunderstands
communication collapses

PQC migration succeeds when:

leadership is aligned
practitioners are capable
vendors are compliant
sectors are synchronized
the public understands the purpose

Stakeholder engagement is the human alignment engine of statewide PQC modernization.

Conclusion

This chapter defines the stakeholder engagement architecture Arizona must operate to ensure that leadership, practitioners, vendors, and the public remain aligned, informed, and coordinated throughout the PQC modernization effort. Engagement is the mechanism that ensures statewide coherence, capability, and trust.

Chapter 31 — Public Communication Strategy: Transparency, Trust, and Non‑Technical Messaging

Transparency, Trust, and Non‑Technical Messaging — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that ensures Arizona can explain PQC to normal humans — without jargon, without fear‑mongering, without technical overload, and without losing the plot.

Public communication is not a side quest. It is a core pillar of statewide modernization.

If the public doesn’t understand what Arizona is doing, why it matters, or how it protects them, then:

trust erodes
misinformation spreads
political support weakens
modernization becomes harder to fund
agencies become defensive
vendors exploit confusion

This chapter defines the public‑facing communication strategy that keeps Arizona’s PQC modernization transparent, trusted, and understood.

31.1 — Why Public Communication Matters

PQC modernization affects:

every resident
every school
every business
every utility
every public safety system
every government service

If the public misunderstands PQC, they may believe:

“Arizona is being hacked.”
“Quantum computers are attacking us today.”
“The government is replacing encryption with something untested.”
“This is a surveillance upgrade.”
“This is unnecessary spending.”

Clear communication prevents these misconceptions.

Public communication is the trust layer of statewide PQC modernization.

31.2 — The Arizona Public Communication Framework (APCF)

Arizona must operate a public communication framework with four pillars:

Clarity — no jargon
Reassurance — no fear
Transparency — no secrecy
Consistency — no contradictions

Each pillar is essential.

31.3 — Core Public Messages

Arizona must communicate five simple messages to the public:

1. “Arizona is upgrading its digital security.”

Not “quantum,” not “cryptography,” not “algorithms.” Just: security upgrade.

2. “This protects your data for the long term.”

People understand “long‑term protection” better than “harvest‑now‑decrypt‑later.”

3. “This is a proactive modernization, not a response to an attack.”

This prevents fear and speculation.

4. “This is a statewide effort across all sectors.”

People trust coordinated action more than isolated upgrades.

5. “This aligns with national security and federal standards.”

This signals legitimacy and necessity.

These messages must appear in every public communication.

31.4 — What NOT to Say to the Public

Arizona must avoid:

algorithm names
protocol names
vendor names
timelines that sound like deadlines
phrases like “quantum threat”
anything that implies imminent danger
anything that implies surveillance
anything that implies instability

Public communication must be calm, confident, and simple.

31.5 — Public Communication Channels

Arizona must communicate through:

1. Public Dashboards

progress
milestones
sector updates
vendor compliance summaries

2. Press Releases

major milestones
statewide announcements
annual reports

3. Public FAQs

simple explanations
common misconceptions
reassurance messaging

4. Educational Materials

infographics
short videos
school‑friendly explanations

5. Media Engagement

interviews
briefings
background sessions

Public communication must be multi‑channel.

31.6 — Public‑Facing Explanations (Templates)

Arizona must maintain ready‑to‑use public explanations.

31.6.1 — “What is PQC?” (Public Version)

“Arizona is upgrading its digital security to protect information from future technologies. This ensures that your data — from school records to public safety systems — stays safe for decades.”

31.6.2 — “Why is Arizona doing this now?” (Public Version)

“We’re modernizing early so Arizona stays ahead of future threats. This is a proactive upgrade, not a response to any incident.”

31.6.3 — “Will this affect me?” (Public Version)

“No. These upgrades happen behind the scenes. You won’t need to change anything.”

31.6.4 — “Is my data safe today?” (Public Version)

“Yes. Arizona is strengthening security to ensure your data stays safe long into the future.”

31.6.5 — “Is this related to surveillance?” (Public Version)

“No. This upgrade is about protecting data, not accessing it.”

31.7 — Public Communication Cadence

Quarterly

statewide progress updates
sector highlights
vendor compliance summaries

Annually

statewide PQC modernization report
public dashboard refresh
public education campaign

As Needed

major milestones
major vendor updates
major federal alignment updates

Cadence ensures predictability.

31.8 — Public Communication Risks & Mitigations

Risk	Description	Mitigation
Public fear	misunderstanding PQC	simple, reassuring messaging
Media misinterpretation	technical complexity	pre‑briefings + FAQs
Vendor spin	misleading claims	statewide validation
Political framing	partisan narratives	consistent statewide messaging
Misinformation	social media distortion	rapid response templates

31.9 — Why Public Communication Determines PQC Success

PQC modernization fails when:

the public is confused
the media misinterprets
vendors mislead
policymakers lose support
modernization becomes politicized

PQC modernization succeeds when:

messaging is clear
trust is maintained
transparency is consistent
the public understands the purpose

Public communication is the legitimacy layer of statewide PQC modernization.

Conclusion

This chapter defines the public communication strategy Arizona must use to ensure that PQC modernization is understood, trusted, and supported by the public. Clear, simple, reassuring messaging is essential to maintaining legitimacy and preventing misinformation.

Chapter 32 — Risk Management & Mitigation: Statewide Cryptographic Risk Governance

Statewide Cryptographic Risk Governance — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter where Arizona stops thinking about PQC as a technical upgrade and starts treating it as a statewide risk ecosystem — one that spans cryptography, vendors, cloud providers, identity systems, OT/ICS, supply chains, and governance.

PQC modernization introduces new risks, new failure modes, and new dependencies that traditional cybersecurity frameworks were never designed to handle.

This chapter defines the statewide risk governance model, the risk categories, the risk scoring system, and the mitigation strategies Arizona must use to ensure PQC modernization is safe, stable, and sovereign.

32.1 — Why PQC Requires a New Risk Model

Traditional risk models assume:

stable algorithms
predictable certificate behavior
mature vendor ecosystems
stable cloud cryptography
short‑lived data sensitivity

PQC breaks all of those assumptions.

PQC introduces:

hybrid negotiation risks
PQC‑only compatibility risks
certificate chain divergence
cloud regression risks
vendor roadmap risks
supply‑chain sovereignty risks
OT/ICS firmware risks
identity fragility risks

Arizona must adopt a PQC‑specific risk model.

32.2 — The Arizona PQC Risk Governance Framework (APQCRGF)

Arizona must operate a statewide risk governance framework with five components:

Risk Identification
Risk Classification
Risk Scoring
Risk Mitigation
Risk Reporting

Each component is mandatory.

32.3 — Component 1: Risk Identification

Arizona must identify risks across six domains:

Cryptographic Risks
Certificate Risks
Identity Risks
Network/VPN Risks
Cloud Risks
OT/ICS Risks
Vendor & Supply‑Chain Risks
Governance Risks

Each domain has unique failure modes.

32.4 — Component 2: Risk Classification

Arizona must classify risks into four categories:

Category A — Immediate Risks

hybrid negotiation failures
certificate chain failures
identity outages
VPN tunnel failures
cloud regression

Category B — Near‑Term Risks

vendor roadmap delays
firmware update delays
cloud PQC lag
certificate lifecycle issues

Category C — Long‑Term Risks

OT/ICS hardware cycles
PQC‑only compatibility
cross‑jurisdictional alignment

Category D — Strategic Risks

supply‑chain sovereignty
vendor consolidation
federal alignment
governance drift

Classification determines urgency.

32.5 — Component 3: Risk Scoring

Arizona must score risks using a five‑factor model:

Factor	Description
Impact	How severe is the failure?
Likelihood	How likely is it to occur?
Detectability	How quickly can it be detected?
Containability	How easily can it be contained?
Recoverability	How easily can it be rolled back?

Each factor is scored 1–5. Total score determines priority.

32.6 — Component 4: Risk Mitigation

Arizona must maintain mitigation strategies for each risk domain.

32.6.1 — Cryptographic Risk Mitigation

Risks:

hybrid negotiation failure
PQC‑only negotiation failure

Mitigations:

fallback configurations
pre‑validated cipher suites
statewide validation

32.6.2 — Certificate Risk Mitigation

Risks:

chain validation failure
OCSP/CRL failure
PQC‑only chain incompatibility

Mitigations:

statewide CA governance
certificate chain freezing
offline CA capability

32.6.3 — Identity Risk Mitigation

Risks:

SSO failure
MFA failure
token signing failure

Mitigations:

hybrid identity fallback
trust store governance
identity validation

32.6.4 — Network/VPN Risk Mitigation

Risks:

tunnel negotiation failure
rekey failure
firmware incompatibility

Mitigations:

hybrid fallback tunnels
firmware validation
statewide VPN standards

32.6.5 — Cloud Risk Mitigation

Risks:

cloud regression
cloud identity failure
cloud KMS failure

Mitigations:

cloud validation
contractual enforcement
cloud rollback procedures

32.6.6 — OT/ICS Risk Mitigation

Risks:

gateway failure
telemetry disruption
firmware signature rejection

Mitigations:

hybrid gateways
segmentation
compensating controls

32.6.7 — Vendor & Supply‑Chain Risk Mitigation

Risks:

foreign cryptographic components
roadmap delays
misrepresentation

Mitigations:

CBOM/SBOM
sovereignty attestation
procurement enforcement

32.6.8 — Governance Risk Mitigation

Risks:

sector drift
inconsistent reporting
weak enforcement

Mitigations:

SPGC authority
SIG coordination
TWG validation

32.7 — Component 5: Risk Reporting

Arizona must maintain:

1. Statewide Risk Register

updated quarterly
reviewed by SPGC

2. Sector Risk Maps

maintained by SIGs

3. Technical Risk Reports

maintained by TWGs

4. Public Risk Summaries

non‑sensitive
transparency‑focused

Risk reporting ensures visibility.

32.8 — High‑Priority PQC Risks (Arizona‑Specific)

Arizona must treat the following as top‑tier risks:

1. Cloud Provider Regression

If a cloud provider silently reverts to classical crypto, the entire state regresses.

2. Identity Fragility

Identity is the most fragile component of PQC modernization.

3. Certificate Chain Divergence

If agencies use inconsistent CA hierarchies, statewide interoperability breaks.

4. Vendor Sovereignty Violations

Foreign cryptographic components introduce national‑security risk.

5. OT/ICS Firmware Constraints

OT/ICS modernization is slow, expensive, and high‑risk.

6. Hybrid Misconfiguration

Hybrid modes are powerful — and easy to misconfigure.

32.9 — Risk Mitigation Playbooks

Arizona must maintain playbooks for:

hybrid TLS failure
PQC‑only TLS failure
identity failure
VPN failure
cloud regression
certificate chain failure
OT/ICS gateway failure
vendor sovereignty breach

These playbooks must be updated annually.

32.10 — Why Risk Governance Determines PQC Success

PQC migration fails when:

risks are invisible
risks are unmanaged
risks are unreported
risks are unmitigated
risks are uncoordinated

PQC migration succeeds when:

risks are identified
risks are classified
risks are scored
risks are mitigated
risks are reported
risks are governed

Risk governance is the stability layer of statewide PQC modernization.

Conclusion

This chapter defines the risk governance architecture Arizona must operate to ensure that PQC modernization is safe, stable, and sovereign. Risk management is the mechanism that prevents failures, contains incidents, and ensures statewide resilience.

Chapter 33 — Future‑Proofing & Long‑Term Strategy: Preparing Arizona for Post‑2030 Cryptographic Evolution

Preparing Arizona for Post‑2030 Cryptographic Evolution — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter where Arizona stops thinking about PQC as a destination and starts treating it as a continuum — a long‑arc modernization cycle that will extend far beyond 2030.

PQC is not the end of cryptography. It is the beginning of a new era.

This chapter defines how Arizona:

stays ahead of future cryptographic shifts
avoids repeating the mistakes of the classical era
builds systems that can evolve
maintains sovereignty over its cryptographic future
prepares for post‑2030 algorithm updates
prepares for post‑quantum‑era threats
prepares for new federal standards
prepares for new supply‑chain realities

This is the chapter that ensures Arizona’s modernization is not just successful, but durable.

33.1 — Why Future‑Proofing Matters

PQC modernization is not a one‑time upgrade. It is the first step in a multi‑decade cryptographic evolution.

Future risks include:

new PQC algorithms
new hybrid models
new attack vectors
new hardware acceleration
new cloud cryptographic behaviors
new OT/ICS constraints
new supply‑chain threats
new federal mandates

Arizona must build systems that can adapt, not just comply.

Future‑proofing is the longevity layer of statewide PQC modernization.

33.2 — The Arizona Future‑Proofing Framework (AFF)

Arizona must operate a future‑proofing framework with five pillars:

Crypto‑Agility
Modular Architecture
Sovereign Supply Chains
Continuous Validation
Long‑Term Governance

Each pillar ensures Arizona can evolve beyond 2030.

33.3 — Pillar 1: Crypto‑Agility

The ability to change algorithms without breaking systems

Crypto‑agility is the most important long‑term capability.

Arizona must ensure:

1. Algorithms can be swapped without downtime

TLS
VPN
identity
certificates
cloud integrations
OT/ICS gateways

2. Key sizes and parameters can be updated

Without rewriting applications.

3. Certificate chains can evolve

Without breaking trust stores.

4. Identity flows can adapt

Without breaking SSO/MFA.

Crypto‑agility prevents Arizona from being trapped by today’s algorithms.

33.4 — Pillar 2: Modular Architecture

Systems must be built to evolve

Arizona must adopt modular architectures that allow:

cryptographic modules to be replaced
identity providers to be swapped
certificate authorities to be updated
cloud integrations to be reconfigured
OT/ICS gateways to be upgraded

Monolithic systems are the enemy of future‑proofing.

Modularity ensures Arizona can adapt to:

new PQC algorithms
new federal standards
new vendor ecosystems
new supply‑chain requirements

33.5 — Pillar 3: Sovereign Supply Chains

Arizona must control its cryptographic destiny

Future threats include:

foreign cryptographic modules
foreign firmware
foreign hardware
foreign legal exposure
foreign cloud dependencies

Arizona must maintain:

1. U.S.‑developed cryptography

No foreign cryptographic components.

2. U.S.‑controlled firmware

No foreign firmware signing keys.

3. U.S.‑controlled hardware

Especially for OT/ICS.

4. CBOM/SBOM enforcement

Continuous, not one‑time.

5. Sovereignty audits

Annual, mandatory, enforceable.

Supply‑chain sovereignty is the strategic defense layer of future‑proofing.

33.6 — Pillar 4: Continuous Validation

Validation must continue beyond 2030

Arizona must maintain:

annual hybrid validation
annual PQC‑only validation
annual cloud validation
annual identity validation
annual certificate validation
annual OT/ICS validation
annual supply‑chain validation

Validation must evolve as:

algorithms evolve
vendors evolve
cloud providers evolve
federal standards evolve

Continuous validation ensures Arizona stays ahead of failures.

33.7 — Pillar 5: Long‑Term Governance

Governance must extend beyond the initial transition

Arizona must maintain:

1. SPGC (permanent)

Not a temporary task force.

2. SIGs (permanent)

Sector coordination must continue.

3. TWGs (permanent)

Technical expertise must remain active.

4. Statewide PQC Roadmap (annual)

Updated every year.

5. Statewide PQC Report (annual)

Published every year.

Governance is the continuity layer of future‑proofing.

33.8 — Preparing for Post‑2030 Algorithm Evolution

NIST will:

update PQC algorithms
introduce new variants
deprecate older versions
publish new hybrid models
publish new implementation guidance

Arizona must prepare for:

1. Algorithm Refresh Cycles

Every 5–10 years.

2. Parameter Updates

Key sizes, signature sizes, KEM parameters.

3. New PQC Families

Lattice → code‑based → multivariate → hash‑based.

4. New Hybrid Models

PQC + PQC PQC + classical (temporary) PQC + hardware‑accelerated

5. New Federal Mandates

OMB, CISA, NIST, DOE, DHS.

Arizona must treat PQC as a living system, not a static standard.

33.9 — Preparing for Post‑Quantum Threats Beyond Cryptography

Quantum computing is not the only future threat.

Arizona must prepare for:

1. AI‑Accelerated Attacks

automated vulnerability discovery
automated protocol fuzzing
automated identity attacks

2. Hardware‑Level Attacks

side‑channel attacks
firmware compromise
supply‑chain tampering

3. Cloud‑Native Threats

cryptographic regression
identity misconfiguration
API token compromise

4. OT/ICS Threats

PQC‑aware malware
firmware signing bypass
gateway compromise

Future‑proofing requires multi‑domain resilience.

33.10 — Preparing for Post‑2030 Cloud Evolution

Cloud providers will:

introduce PQC‑accelerated hardware
introduce PQC‑native identity
introduce PQC‑native KMS
introduce PQC‑native APIs
introduce PQC‑native telemetry

Arizona must:

validate cloud behavior annually
enforce contractual requirements
maintain cloud fallback mechanisms
maintain cloud sovereignty requirements

Cloud is the largest long‑term dependency.

33.11 — Preparing for Post‑2030 OT/ICS Evolution

OT/ICS modernization cycles are:

slow
expensive
hardware‑bound
safety‑critical

Arizona must plan for:

1. PQC‑native PLCs

2035–2040.

2. PQC‑native sensors

2035–2045.

3. PQC‑native SCADA systems

2035–2040.

4. PQC‑native firmware signing

Mandatory.

OT/ICS modernization is a decade‑long journey.

33.12 — Preparing for Post‑2030 Identity Evolution

Identity will evolve faster than any other domain.

Arizona must prepare for:

PQC‑native SSO
PQC‑native MFA
PQC‑native tokens
PQC‑native trust stores
decentralized identity models
hardware‑backed PQC identity

Identity is the most dynamic future‑proofing domain.

33.13 — Why Future‑Proofing Determines PQC Success

PQC migration fails when:

systems are static
algorithms are hard‑coded
vendors control the roadmap
cloud providers regress
supply chains are opaque
governance is temporary

PQC migration succeeds when:

systems are agile
architectures are modular
sovereignty is enforced
validation is continuous
governance is permanent

Future‑proofing is the longevity engine of statewide PQC modernization.

Conclusion

This chapter defines the long‑term strategy Arizona must use to ensure that PQC modernization remains resilient, sovereign, and adaptable beyond 2030. Future‑proofing is the mechanism that ensures Arizona stays ahead of cryptographic evolution, vendor ecosystems, cloud behavior, and emerging threats.

Chapter 34 — Implementation Roadmap: The Complete 2026–2035 Timeline

The Complete 2026–2035 Timeline — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that ties everything together — governance, procurement, validation, monitoring, training, vendor enforcement, sector alignment, and long‑term strategy — into a single, coherent, statewide execution plan.

This is the chapter that shows:

what happens when
who is responsible
what must be completed
what dependencies exist
what risks must be managed
how Arizona moves from 2026 → 2035 without breaking anything

This is the master timeline for Arizona’s PQC modernization.

34.1 — Roadmap Overview (2026–2035)

Arizona’s PQC modernization unfolds in three phases:

Phase 1 — Foundation (2026–2027)

Inventory, governance, procurement, hybrid deployment.

Phase 2 — Stabilization (2028–2029)

Hybrid hardening, PQC‑only preparation, vendor enforcement.

Phase 3 — Transition & Future‑Proofing (2030–2035)

PQC‑only cutover, OT/ICS modernization, long‑term evolution.

Each phase builds on the previous one.

34.2 — 2026: Inventory, Governance, and Procurement

Q1–Q2 2026

SPGC established
SIGs established
TWGs established
statewide PQC roadmap published
statewide CA modernization plan drafted

Q2–Q3 2026

statewide cryptographic inventory
statewide certificate inventory
statewide identity inventory
statewide VPN inventory
statewide cloud inventory
statewide OT/ICS inventory

Q3–Q4 2026

procurement templates finalized
vendor requirements published
CBOM/SBOM requirements enforced
sovereignty attestation required
statewide validation lab operational

Outcome: Arizona knows what it has, who controls it, and what must change.

34.3 — 2027: Hybrid Deployment Across All Sectors

Q1 2027

hybrid TLS deployment begins
hybrid VPN deployment begins
hybrid identity deployment begins
hybrid certificate issuance begins

Q2–Q3 2027

cloud hybrid validation
identity hybrid validation
VPN hybrid validation
certificate hybrid validation

Q4 2027

statewide hybrid deployment milestone
vendor hybrid compliance enforcement
statewide hybrid dashboards published

Outcome: Arizona is fully hybrid across all sectors.

34.4 — 2028: Hybrid Stabilization & Vendor Enforcement

Q1–Q2 2028

hybrid tuning
hybrid performance optimization
hybrid fallback validation
hybrid incident response drills

Q2–Q3 2028

vendor hybrid validation
vendor roadmap enforcement
vendor sovereignty audits

Q4 2028

statewide hybrid stability certification
statewide PQC‑only preparation begins

Outcome: Hybrid is stable, validated, and enforceable.

34.5 — 2029: PQC‑Only Preparation

Q1 2029

PQC‑only TLS testing
PQC‑only VPN testing
PQC‑only identity testing
PQC‑only certificate chain testing

Q2–Q3 2029

cloud PQC‑only validation
vendor PQC‑only validation
OT/ICS PQC‑only gateway testing

Q4 2029

statewide PQC‑only readiness report
statewide PQC‑only cutover plan finalized

Outcome: Arizona is ready for PQC‑only transition.

34.6 — 2030: PQC‑Only Transition (Core IT Systems)

Q1 2030

PQC‑only TLS cutover (agencies)
PQC‑only identity cutover
PQC‑only VPN cutover

Q2 2030

PQC‑only cloud integrations
PQC‑only certificate issuance
PQC‑only trust store updates

Q3–Q4 2030

statewide PQC‑only validation
statewide PQC‑only dashboards
statewide PQC‑only compliance enforcement

Outcome: Core IT systems are PQC‑only.

34.7 — 2031–2035: OT/ICS Modernization & Long‑Term Evolution

OT/ICS modernization is the longest and most complex part of the roadmap.

2031

hybrid → PQC‑only gateway transition
firmware signing modernization
segmentation upgrades

2032

PQC‑native SCADA pilots
PQC‑native PLC pilots
PQC‑native telemetry pilots

2033

statewide OT/ICS PQC‑only transition
statewide OT/ICS validation

2034

PQC‑native hardware adoption
PQC‑native firmware signing enforcement

2035

statewide OT/ICS PQC‑only certification
statewide PQC modernization complete

Outcome: Arizona becomes the first state with fully PQC‑modernized OT/ICS infrastructure.

34.8 — Cross‑Sector Milestones

Agencies

hybrid by 2027
PQC‑only by 2030

Education

hybrid by 2027
PQC‑only by 2030

Public Safety

hybrid by 2027
PQC‑only by 2030 (CJIS‑aligned)

Critical Infrastructure

hybrid by 2028
PQC‑only by 2035

34.9 — Vendor Milestones

2026

CBOM/SBOM required
sovereignty attestation required

2027

hybrid support required

2028

hybrid validation required

2029

PQC‑only readiness required

2030

PQC‑only validation required

2031–2035

OT/ICS PQC‑native hardware required

34.10 — Governance Milestones

SPGC

annual roadmap updates
annual statewide PQC report
quarterly compliance reviews

SIGs

quarterly sector reports
sector risk maps
sector validation coordination

TWGs

annual test suite updates
annual validation cycles
annual technical guidance

34.11 — Why the Roadmap Determines PQC Success

PQC modernization fails when:

timelines drift
vendors stall
sectors misalign
cloud providers regress
identity systems break
OT/ICS modernization lags

PQC modernization succeeds when:

timelines are clear
milestones are enforced
vendors are accountable
sectors move together
validation is continuous
governance is strong

The roadmap is the execution engine of statewide PQC modernization.

This chapter provides the complete statewide implementation roadmap for Arizona’s PQC modernization — from 2026 to 2035. It defines the milestones, dependencies, responsibilities, and timelines that ensure Arizona transitions safely, coherently, and sovereignly into the post‑quantum era.

Chapter 35 — Conclusion & Executive Summary: The Blueprint for Statewide PQC Modernization

The Blueprint for Statewide PQC Modernization — How Arizona Can Execute PQC Migration at Scale (2026 Edition)

This is the chapter that closes the loop — the chapter that distills 34 chapters of architecture, governance, procurement, validation, risk, and strategy into a single, coherent, statewide blueprint.

This is the chapter that a Governor, CIO, CISO, Superintendent, Sheriff, Utility Operator, or Legislator can read and immediately understand:

what Arizona must do
why it must be done
how it must be done
who must do it
when it must be completed
what risks must be managed
what vendors must comply with
what the long‑term strategy is

This is the executive summary of the entire modernization program.

35.1 — The Core Premise

Arizona must modernize its cryptography because:

quantum computers will eventually break classical encryption
adversaries are harvesting encrypted data today
federal standards require PQC adoption
statewide systems must remain secure for decades
critical infrastructure must remain sovereign
cloud providers must be held accountable
vendors must modernize or be replaced

PQC modernization is not optional. It is a statewide security, sovereignty, and modernization imperative.

35.2 — The Statewide Strategy (One Sentence)

Arizona will deploy hybrid cryptography statewide by 2027, stabilize and validate it by 2028–2029, transition core IT systems to PQC‑only by 2030, and complete OT/ICS modernization by 2035 — governed by SPGC, enforced through procurement, validated through statewide testing, and supported by training, monitoring, and risk governance.

That is the entire program in one line.

35.3 — The Five Pillars of Statewide PQC Modernization

Arizona’s modernization rests on five pillars:

1. Governance

SPGC → SIGs → TWGs Clear authority, clear roles, clear enforcement.

2. Procurement

Contractual requirements, CBOM/SBOM, sovereignty, validation.

3. Validation

Statewide test suites, hybrid and PQC‑only testing, cloud and OT/ICS validation.

4. Monitoring

TLS, VPN, identity, certificates, cloud, OT/ICS telemetry.

5. Workforce Enablement

Training, certification, vendor‑specific capability.

These pillars ensure modernization is coherent, enforceable, and resilient.

35.4 — The Statewide Roadmap (2026–2035)

2026 — Inventory & Governance

SPGC, SIGs, TWGs established
statewide inventories completed
procurement templates finalized
validation lab operational

2027 — Hybrid Deployment

hybrid TLS, VPN, identity, certificates
cloud and vendor hybrid validation

2028 — Hybrid Stabilization

tuning, fallback validation, vendor enforcement

2029 — PQC‑Only Preparation

PQC‑only testing across all domains
statewide readiness assessment

2030 — PQC‑Only Transition (Core IT)

PQC‑only TLS, VPN, identity, certificates
cloud PQC‑only integrations

2031–2035 — OT/ICS Modernization

PQC‑only gateways
PQC‑native firmware
PQC‑native SCADA and PLCs

This roadmap ensures safe, staged, statewide modernization.

35.5 — The Vendor Enforcement Model

Vendors must comply with:

hybrid support
PQC‑only readiness
CBOM/SBOM
sovereignty requirements
validation requirements
roadmap timelines

Enforcement mechanisms:

contract clauses
renewal conditions
validation requirements
vendor freeze mechanisms
SPGC authority

Vendors who fail to comply are disqualified.

35.6 — The Sector Alignment Model

Arizona must modernize as one system, not four:

Agencies — hybrid by 2027, PQC‑only by 2030
Education — cloud‑aligned, PQC‑only by 2030
Public Safety — CJIS‑aligned, PQC‑only by 2030
Critical Infrastructure — hybrid by 2028, PQC‑only by 2035

Cross‑sector coordination prevents fragmentation.

35.7 — The Risk Governance Model

Arizona must manage risks across:

cryptography
certificates
identity
VPN
cloud
OT/ICS
supply chains
governance

Risk governance ensures stability, safety, and resilience.

35.8 — The Long‑Term Strategy (2030–2040)

Arizona must:

maintain crypto‑agility
maintain modular architectures
maintain sovereign supply chains
maintain continuous validation
maintain permanent governance

PQC is not the end — it is the beginning of a multi‑decade evolution.

35.9 — The Executive Summary

Arizona’s PQC Modernization Program

Objective: Protect Arizona’s data, systems, and critical infrastructure from future cryptographic threats.

Mandate: HB2809 + federal alignment (NIST, CISA, OMB, CJIS, DOE, DHS).

Strategy: Hybrid by 2027 → PQC‑only by 2030 → OT/ICS PQC‑only by 2035.

Governance: SPGC (authority), SIGs (coordination), TWGs (technical).

Procurement: Contractual enforcement, CBOM/SBOM, sovereignty, validation.

Validation: Statewide hybrid and PQC‑only test suites.

Monitoring: TLS, VPN, identity, certificates, cloud, OT/ICS telemetry.

Training: Foundational → role‑specific → vendor‑specific → certification.

Risk: Statewide risk register, sector risk maps, continuous mitigation.

Outcome: Arizona becomes the first state with a fully modernized, sovereign, PQC‑ready infrastructure.

35.10 — Final Statement

Arizona’s PQC modernization is:

the most ambitious statewide cryptographic upgrade in U.S. history
the first statewide program to enforce supply‑chain sovereignty
the first to unify agencies, education, public safety, and critical infrastructure
the first to mandate hybrid → PQC‑only transition across all sectors
the first to build a 2035 OT/ICS modernization plan

This blueprint ensures Arizona is not just compliant — but sovereign, resilient, and decades ahead of the curve.

Post‑Quantum Cryptography (PQC) Modernization — 2019–2026 Longitudinal Practitioner Dataset & Analytic Framework

This analysis is grounded in more than a decade of practitioner‑level experience in quantum technology research, post‑quantum cryptography, and large‑scale cryptographic‑modernization efforts across global financial institutions, advanced‑research ecosystems, and national‑level governance bodies. The methodology reflects long‑horizon exposure to quantum‑risk modeling, cryptographic‑lifecycle management, and the operational realities of migrating complex, multi‑sector environments toward NIST‑approved post‑quantum standards.

The analysis was developed using a practitioner‑first, governance‑aligned methodology grounded in national standards, state legislative analysis, and cross‑sector threat modeling. It incorporates federal PQC guidance, NIST standards, Arizona legislative text, and statewide cybersecurity assessments.

The author, Hunter Storm, brings extensive expertise across emerging and disruptive technologies (EDTs), including post‑quantum cryptography (PQC), quantum technologies, and hybrid cyber‑physical‑psychological threat modeling. Her background includes:

involvement in PQC and quantum‑technology working groups
advisory work across financial, research, and critical infrastructure domains
leadership in enterprise architecture and cross‑domain governance
deep experience in Security Operations Center (SOC) design and operational architecture
research leadership in statewide cybersecurity posture assessments
authorship of Arizona’s 2026 Material Weaknesses Audit, Statewide Action Plan, and Cyber Fusion Center roadmap

Her work integrates EDT strategy, governance modernization, and practitioner‑layer security, with a focus on long‑horizon risk, cryptographic transition planning, and institutional resilience.

Data Sources

The findings draw from a uniquely broad and longitudinal set of practitioner‑derived inputs, including:

Enterprise quantum‑technology research (2019–2026) — direct involvement in Wells Fargo’s foundational Quantum Technology Research Team, including early quantum‑risk modeling, hybrid cryptography evaluation, and enterprise‑scale modernization planning.
QED‑C and national‑level PQC governance work — participation in technical advisory councils, quantum‑technology working groups, and cross‑sector modernization initiatives supporting U.S. PQC readiness.
PQC research and migration frameworks — exposure to industry‑leading PQC transition models, hybrid‑mode deployment patterns, and cryptographic‑inventory methodologies.
Cross‑sector cryptographic‑modernization engagements — practitioner‑level work supporting financial institutions, research organizations, public sector agencies, and critical infrastructure operators preparing for PQC transition.
Operational observations across cryptographic lifecycles — including key‑management evolution, certificate‑authority modernization, protocol migration, and dependency mapping across multi‑environment architectures.
Federal guidance and national frameworks — NIST PQC standards, CISA modernization advisories, federal cryptographic‑transition roadmaps, and cross‑sector risk‑management resources.
State‑level statutory and governance materials — including Arizona HB2809, statewide modernization plans, legislative analyses, and public sector cryptographic‑readiness assessments.
Practitioner interviews and SME consultations — with cryptographers, quantum researchers, security architects, public sector leaders, and critical infrastructure operators.
Review of federal PQC directives, including NIST standards, OMB memoranda, CISA guidance, and national‑level modernization expectations.
Analysis of Arizona’s statutory and regulatory landscape, with emphasis on HB2809, statewide cybersecurity governance structures, and sector‑specific obligations.
Cross‑sector practitioner interviews and operational insights from state agencies, critical‑infrastructure operators, and security leaders responsible for implementing cryptographic transitions.
Comparative assessment of state and federal requirements, identifying alignment points, gaps, dependencies, and areas requiring coordinated governance action.
Evaluation of implementation readiness, focusing on crypto‑agility, inventory maturity, risk exposure, and institutional capacity to execute PQC migration at scale.
SDSUG internal analysis and statewide PQC‑readiness modeling — integrating cross‑sector insight from Arizona’s practitioner community and institutional ecosystem.

Analytic Approach

The analysis applies a structured, practitioner‑driven lens that emphasizes:

Cryptographic‑lifecycle realism — assessing how long‑term key‑management, certificate‑authority, and protocol decisions shape PQC migration complexity.
Hybrid‑mode transition patterns — evaluating the operational viability of classical‑plus‑PQC deployments across diverse architectures.
Systemic dependency mapping — identifying how cryptographic weaknesses propagate across interconnected systems, supply chains, and multi‑sector environments.
Governance and statutory alignment — interpreting federal mandates, state requirements, and sector‑specific obligations through a modernization‑ready lens.
Quantum‑risk modeling — integrating long‑horizon analysis of quantum‑computing trajectories, algorithmic exposure, and cryptographic deprecation timelines.
Institutional memory and continuity — assessing how workforce stability, architectural lineage, and organizational maturity influence PQC readiness.

Scope

The PQC Modernization Series assesses:

statewide PQC readiness
sector‑specific migration requirements
cryptographic‑inventory maturity
governance and statutory alignment
hybrid‑mode deployment feasibility
critical infrastructure exposure
public sector modernization constraints
enterprise‑scale migration patterns
supply‑chain and vendor‑dependency risks

The analysis prioritizes clarity, implementability, and statewide resilience, emphasizing the decisions, timelines, and governance structures required to support Arizona’s transition to post‑quantum cryptography.

Limitations

The analysis is practitioner‑driven and qualitative. It does not rely on vendor‑reported metrics, marketing‑driven maturity models, or survey‑based scoring. Instead, it reflects:

longitudinal quantum technology experience
cryptographic lifecycle analysis
governance and statutory interpretation
cross‑sector modernization insight
SME‑level consultation
publicly available information
limited access to proprietary systems

Where quantitative data is unavailable or inconsistent, findings are presented using structured qualitative scoring consistent with industry‑standard risk assessment practices.

Why This Methodology Is Appropriate

PQC modernization is not a purely technical exercise. It is a governance, lifecycle, and dependency‑driven transformation shaped by:

cryptographic‑inventory complexity
architectural lineage
institutional memory
workforce readiness
statutory requirements
systemic dependencies

These conditions cannot be captured through short‑term surveys or tool‑generated metrics. They require long‑horizon, practitioner‑level exposure to quantum risk evolution, cryptographic modernization, and cross‑sector operational realities.

This methodology provides a grounded, accurate, and actionable foundation for statewide PQC transition.

About This Report

How Arizona Can Execute PQC Migration at Scale is published periodically (state–federal alignment changes only) as part of Research to provide practitioner‑driven intelligence for Arizona’s cybersecurity, governance, and critical‑infrastructure communities. This report contributes to the Post‑Quantum Cryptography (PQC) Modernization Series, which delivers statewide guidance on statutory alignment, governance readiness, and quantum‑resilient modernization.

For additional publications and analysis, visit the Sonoran Desert Security (SDSUG) Research hub.

Hunter Storm, President of SDSUG smiling

By Hunter Storm

President, Sonoran Desert Security (SDSUG)

https://hunterstorm.com/

Related Reports

These companion reports are part of the Sonoran Desert Security (SDSUG) Research Series. For the full collection, visit the Sonoran Desert Security (SDSUG) Research hub.

Version

Version 1.0 — Published April 2026

How to Cite This Report

Storm, Hunter. How Arizona Can Execute PQC Migration at Scale. Sonoran Desert Security (SDSUG), Version 1.0, 2026.

For full citation standards and usage permissions, see the Sonoran Desert Security (SDSUG) Citation and Usage Policy.

Disclaimer

This report is provided for educational and informational purposes only. Sonoran Desert Security (SDSUG) does not provide legal, regulatory, or compliance advice. All analysis reflects practitioner‑level interpretation of publicly available information at the time of publication.

Sonoran Desert Security (SDSUG) is Arizona’s longest‑running cybersecurity community and a central institution in the region’s security ecosystem. Established in 2001 and operating continuously for more than 25 years, Sonoran Desert Security (SDSUG) provides practitioner‑led leadership, vendor‑neutral governance, and trusted peer collaboration across the Southwest. Through its annual research, ecosystem mapping, and community programs, Sonoran Desert Security (SDSUG) strengthens regional resilience and serves as a stable anchor for Arizona’s cybersecurity practitioners, organizations, and critical infrastructure partners. Sonoran Desert Security (SDSUG) also publishes independent research used by organizations and policymakers across Arizona, the broader Southwest, and national and international security, technology, and governance communities.

Explore Sonoran Desert Security (SDSUG)

Start Here
Guided introduction to SDSUG.

Membership
Join SDSUG for trusted peer collaboration and professional networking.

Leadership
Meet the team guiding SDSUG’s direction.

About SDSUG
Our mission, history, and values.

Events & Meetings
Upcoming topics, speakers, certification prep, and education.

Sponsors
Organizations supporting SDSUG’s.

SDSUG at a Glance
Overview and orientation FAQ.

Safety & Incident Response
Standards, trained officers, and incident‑response protocols.

Site Index
A full directory of SDSUG web pages and resources.

Start Here

Events

Join SDSUG

Last Updated: April 2026