← Back to Blog

Why PQC Migration Plan Generator Exists

Why PQC Migration Plan Generator Exists

TL;DR. NIST finalized PQC standards in 2024 (FIPS 203 / 204 / 205). Audit TLS, DNSSEC, and code-signing now so the 2035 CNSA deadline is an incremental migration, not a forklift.

The PQC Migration Plan Generator is the audit you reach for when you already suspect a problem in this dimension and need a fast, copy-paste-able fix list. It reuses the same chrome as every other jwatte.com tool — deep-links from the mega analyzers, AI-prompt export, CSV/PDF/HTML download — but the checks it runs are narrow and specific to the dimension described above.

Check the boxes for the cryptographic surfaces you operate (TLS, SSH host keys, code signing, S/MIME, IPsec/IKEv2, Git commit signing, blockchain validators, wallets, DKIM, DNSSEC, WebAuthn). Pick your jurisdiction (federal, EU, healthcare, finance) and shelf-life tolerance. The generator emits a phased post-quantum migration plan aligned to NSM-10 / CNSA 2.0 deadlines, with vendor-specific config knobs for nginx / Apache / Caddy / OpenSSH / Cosign / Sigstore / Let

Why this dimension matters

NIST finalized post-quantum cryptography standards in 2024 (FIPS 203 = ML-KEM, FIPS 204 = ML-DSA, FIPS 205 = SLH-DSA). CNSA 2.0 mandates PQC for US national-security systems by 2035, and major CAs are already issuing hybrid classical+PQ certificates. Sites that audit their current TLS / DNSSEC / code-signing posture today can migrate incrementally; sites that wait face a forklift migration.

Common failure patterns

  • TLS cert issued for > 398 days — browsers enforce a 398-day maximum (since 2020). Audits still find long-dated certs on legacy systems that will simply stop being trusted on renewal.
  • RSA-2048 signatures when the CA supports ECDSA-P-256 — ECDSA is faster, smaller, and equally secure today. For PQC readiness, the migration path is easier from ECDSA than from RSA.
  • DNSSEC with RSASHA1 (algorithm 5) — deprecated since 2020. Rekey to RSASHA256 (8) or ECDSAP256SHA256 (13) at minimum.
  • Code-signing with SHA-1 or MD5 — trust stores have been rejecting these since 2017. Legacy MSI installers and Linux package signatures are the most common offenders.

How to fix it at the source

Run a TLS / DNSSEC / code-signing inventory today. For TLS: use short-lived certs (Let's Encrypt 90-day renewal is optimal) + automate renewal via ACME. For DNSSEC: rekey to ECDSAP256SHA256. For PQC readiness: watch for OpenSSL 3.x + BoringSSL PQC support; migrate to hybrid ML-KEM+X25519 as soon as your CDN supports it (Cloudflare shipped Kyber in 2023, AWS announced PQ TLS in 2024).

Thresholds that matter

Signal Target
TLS cert lifetime ≤ 398 days (browser-enforced). Optimal: 90 days via Let's Encrypt + ACME automation.
DNSSEC algorithm ECDSAP256SHA256 (13) or Ed25519 (15). RSASHA1 (5) is deprecated.
Code-signing hash SHA-256 or SHA-384. SHA-1 and MD5 are rejected by every major trust store.
TLS minimum version 1.2 minimum, 1.3 preferred. Disable 1.0 and 1.1.

When to run the audit

  • After a major site change — redesign, CMS migration, DNS change, hosting platform swap.
  • Quarterly as part of routine technical hygiene; the checks are cheap to run repeatedly.
  • Before an investor / client review, a PCI scan, a SOC 2 audit, or an accessibility-compliance review.
  • When a downstream metric drops (rankings, conversion, AI citations) and you need to rule out this dimension as the cause.

Reading the output

Every finding is severity-classified. The playbook is the same across tools:

  • Critical / red — same-week fixes. These block the primary signal and cascade into downstream dimensions.
  • Warning / amber — same-month fixes. Drag the score, usually don't block.
  • Info / blue — context only. Often what a PR reviewer would flag but that doesn't block merge.
  • Pass / green — confirmation. Keep the control in place.

Every audit also emits an "AI fix prompt" — paste into ChatGPT / Claude / Gemini for exact copy-paste code patches tied to your specific stack.

Related tools in this family

Fact-check notes and sources

This post is informational and not a substitute for professional consulting. Mentions of third-party platforms in the tool itself are nominative fair use. No affiliation is implied.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026