ML-DSA-44 signature is 2,420 bytes. An ECDSA P-256 signature is 72 bytes. That is a 33x jump, and it lands in every certificate chain, every TLS handshake, and every embedded device with a fixed buffer size in your environment. You can read that number in a standard. You only feel it when you issue the certificate and watch what breaks.
That gap between having read the standard and having run the standard is where post-quantum migrations quietly go wrong. So we built a place to close it. The PQC Center of Excellence is Encryption Consulting’s open hub for learning post-quantum cryptography and, more importantly, for practicing it. Study the finalized standards, watch the primers, then spin up a free SaaS PKI sandbox and issue a quantum-safe certificate before your next planning meeting.
TL;DR
- The PQC Center of Excellence is a free hub combining post-quantum cryptography (PQC) research, video primers, case studies, and a live sandbox called the PQC Playground.
- In the Playground you can stand up a Root CA and Issuing CA on ML-DSA, launch a pre-designed or fully deployed hierarchy, and issue and validate quantum-safe certificates end to end.
- Three NIST standards are final: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), published August 2024. HQC and FN-DSA are still in the pipeline.
- Size is the practical problem nobody plans for. An ML-DSA certificate chain runs roughly 14 KB to 18 KB against about 586 bytes for an ECDSA chain, which pushes past TCP’s typical 14.5 KB initial congestion window.
- Executive Order 14412 sets December 31, 2030 for post-quantum key establishment and December 31, 2031 for digital signatures on federal high value assets. NIST IR 8547 puts RSA and ECDSA on a path to deprecation by 2030 and disallowed status after 2035.
- Start with discovery and a test hierarchy, not a rip-and-replace plan. The Lab is built for exactly that first step.
Who This Is For
| If you are | Start with | Because |
|---|---|---|
| A PKI or crypto engineer | The PQC Playground | You need to see ML-DSA chain behavior before you design one |
| A security architect | The white papers and the 9-phase migration guide | You are choosing between staged, hybrid, and CNSA 2.0 aligned approaches |
| A CISO or compliance lead | The video primers and the deadline table below | You need the regulatory picture and a defensible timeline |
| An app or platform owner | The size and performance section below | Your service is where the certificate size actually lands |
Why We Built It
There is a specific kind of failure that shows up about six months into a PQC program. The roadmap looks excellent. The steering committee is happy. Then someone tries to enroll the first ML-DSA certificate against the real PKI and discovers that the CA software version in production does not support the algorithm, that the middleware chokes on a certificate several times the expected size, or that nobody can say with confidence which of the 400 internal applications will break when the chain changes.
None of that is discoverable from a slide deck. It is discoverable from twenty minutes in a sandbox.
That is the reasoning behind the Center of Excellence. The reading material and the primers get your team fluent in the vocabulary. The Playground gets them fluent in the behavior. Both are free, both are open, and neither requires you to touch a production system to learn something useful.
There is a second reason. Post-quantum migration is not really a cryptography project, it is an inventory and agility project. Hardening the infrastructure you run today is the groundwork for a quantum-safe tomorrow. You cannot migrate what you have not found, and you cannot swap an algorithm quickly if every certificate is hardcoded, manually issued, and undocumented. Crypto agility, the ability to change cryptographic primitives fast and with confidence as standards shift, is the actual deliverable. Teams that build it now defuse harvest-now-decrypt-later risk, the practice of collecting encrypted traffic today to decrypt it once a quantum computer exists, instead of scrambling the day that computer arrives.
What Is Inside the PQC center of Excellence
The Standards and Research Library
A curated set of blogs, case studies, and white papers covering the ground you need before you commit to an approach. That includes PQC Migration in 2026: Building a Roadmap That Survives Contact With Production, Decoding NIST PQC Standards, and our 12-month playbook for digital trust professionals. The white papers go deeper on sector-specific pressure, including PQC for financial services and the signature selection problem, where the choice between ML-DSA, SLH-DSA, and eventually FN-DSA has real consequences for certificate size, verification cost, and hardware support.
If you want the definitions rather than the opinions, the Education Center covers Introduction to Post-Quantum Cryptography and What Is CNSA 2.0 as standalone explainers.
The PQC Playground
This is the part we would point a hands-on engineer to first. The Playground is a free SaaS PKI sandbox where you can stand up a Root CA and an Issuing CA on ML-DSA, launch a pre-designed hierarchy or a fully deployed one if you would rather skip the setup, then issue quantum-safe certificates and validate them end to end.
No production dependency, no procurement cycle, no risk to anything you care about. The goal is that your team’s first quantum-safe certificate is issued in a lab, not in an outage postmortem.
The Production Toolchain
When the sandbox work turns into a real program, the Lab connects to the platforms that carry it:
- CertSecure Manager for certificate visibility, automated lifecycle management across CAs, and policy-driven enrollment via ACME, SCEP, and EST.
- CBOM Secure for continuous, automated inventory of every cryptographic asset in your environment, with audit-ready reporting aligned to PCI DSS, FIPS SP 800, and SOC 2.
- CodeSign Secure for HSM-backed code signing with CI/CD automation and PQC-ready support for ML-DSA and LMS.
Your First Hour in the Playground
If you only have an hour, spend it like this.
1. Stand up a Root CA on ML-DSA: Note how long key generation takes compared to what your team expects from RSA or ECDSA.
2. Add an Issuing CA and build the chain: This is where hierarchy design decisions start to show their cost.
3. Issue a leaf certificate and export the full chain: Measure it. Compare that number against the buffer sizes in your own middleware, load balancers, and embedded clients.
4. Validate the chain end to end: Watch what your validation path does with a signature several thousand bytes long.
5. Write down the three things that surprised you: Those three things are the real input to your roadmap, and they are almost never the things on the original roadmap.
The Size Problem Nobody Plans For
Post-quantum certificates are not a drop-in swap, and the reason is arithmetic rather than cryptography. The sizes below come from FIPS 204 and are the ones that will land in your chain.
| Algorithm | Public key (bytes) | Signature (bytes) |
|---|---|---|
| ECDSA P-256 | 65 | 72 |
| RSA-2048 | 272 | 256 |
| ML-DSA-44 | 1,312 | 2,420 |
| ML-DSA-65 | 1,952 | 3,309 |
| ML-DSA-87 | 2,592 | 4,627 |
For key establishment, ML-KEM-768 uses a 1,184 byte encapsulation key and a 1,088 byte ciphertext, per the IETF ML-KEM for TLS 1.3 draft. ML-KEM-1024 uses 1,568 bytes for both.
The compounding effect is what matters. A typical ECDSA certificate chain is around 586 bytes. The equivalent ML-DSA chain runs roughly 14 KB to 18 KB depending on the parameter sets chosen, which pushes past the roughly 14.5 KB initial congestion window most TCP connections start with. That means an extra round trip on the first handshake, on every new connection, before your application sends a single byte.
This is why we keep saying the Playground work has to happen before the roadmap work. The certificate size question is not answerable from a spec sheet. It is answerable by issuing one and pointing it at your own stack. RFC 9881 now defines the ML-DSA algorithm identifiers for X.509, so the certificates you build in the Lab use the same encoding your production CA eventually will.
The Clock You Are actually Running against
The Center of Excellence page shows 2035 as the year every system is expected to be quantum-safe. That is the outer edge, not the target. The dates that will land on your calendar first are closer.
| Date | What changes | Who it hits |
|---|---|---|
| March 15, 2026 | Public TLS certificate maximum validity drops to 200 days (CA/B Forum SC-081v3) | Anyone running public TLS |
| September 2026 | Federal agency PQC migration plans due to OMB (EO 14412) | Federal agencies |
| March 15, 2027 | Public TLS certificate maximum validity drops to 100 days | Anyone running public TLS |
| March 15, 2029 | Public TLS certificate maximum validity drops to 47 days | Anyone running public TLS |
| End of 2030 | RSA and ECDSA deprecated per NIST IR 8547; federal high value assets must use post-quantum key establishment; federal contractors must meet NIST PQC standards | Broad |
| End of 2031 | Federal high value assets must use post-quantum digital signatures | Federal and contractors |
| 2035 | RSA and ECDSA disallowed per NIST IR 8547; CNSA 2.0 target for national security systems | Broad |
Two of those rows deserve a closer look.
The standards are still moving: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) were finalized in August 2024. NIST selected HQC in March 2025 as a backup key encapsulation mechanism built on different math from ML-KEM, and FN-DSA (FIPS 206) has been in draft since August 2025 with finalization expected around late 2026 or early 2027. Three standards are production-ready today. Two more are coming, which is precisely why agility matters more than any single algorithm choice.
The certificate lifetime schedule is the sleeper item: The CA/Browser Forum’s SC-081v3 ballot has nothing to do with quantum computing, and it will still shape your PQC timeline more than most PQC guidance will. A team that cannot renew on a 47-day cycle is not going to swap an algorithm across the estate on any cycle. The automation you build for one is the automation you need for the other.
Our Take: Agility Is a Muscle, Not a Milestone
Here is what we would actually recommend, based on the PQC programs we have run.
Do not start with algorithm selection: Start with discovery. The most common finding in a first cryptographic inventory is not weak crypto, it is unknown crypto: certificates nobody owns, libraries pinned to versions nobody tracks, signing keys in a build server that predates the current team. Until that inventory exists, every migration estimate is a guess. This is the entire reason CBOM Secure exists and why we put cryptographic discovery ahead of algorithm decisions in our 9-phase PQC migration guide.
Treat the sandbox as a required step, not a nice-to-have: Give two engineers a week in the Playground before you write the roadmap. What they find about certificate sizes, chain validation behavior, and HSM support will change the plan, and it is far cheaper to change a plan than a deployment.
Pick parameter sets deliberately: ML-DSA-87 is not automatically the responsible choice. Going from ML-DSA-44 to ML-DSA-87 nearly doubles your signature size for a security margin most enterprise use cases do not need. Unless you are bound by CNSA 2.0, which does specify the higher parameter sets for national security systems, size and performance should carry real weight in the decision.
Assume you will do this more than once: FN-DSA is not final. HQC is not final. Guidance will keep moving. Architect for algorithm substitution, with certificate automation and centralized policy, and the second migration costs a fraction of the first. Architect for a single one-time cutover and you will pay full price every time the standards move.
Be honest about the hardware: HSM firmware, smart cards, network appliances, and embedded devices set the real floor on your timeline. Some of what is in your environment right now will never support ML-DSA and will need replacement on a procurement cycle, not a sprint cycle. Find those first, because they are the long pole.
FAQ
Is the PQC Center of Excellence free?
Yes. The research library, white papers, case studies, and video primers are open to everyone. The PQC Playground is a free SaaS sandbox for standing up a quantum-safe PKI hierarchy and issuing test certificates. You only move into a paid engagement if you decide you want production deployment or advisory support.
What can I actually build in the PQC Playground?
You can stand up a Root CA and an Issuing CA on ML-DSA, or launch a pre-designed or fully deployed hierarchy if you want to skip the setup, then issue and validate quantum-safe certificates end to end. It runs entirely inside the Lab, so nothing touches your production PKI.
Which post-quantum algorithms are ready for production use?
Three NIST standards are final: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a hash-based signature alternative. HQC was selected in March 2025 as a backup key encapsulation mechanism, and FN-DSA (FIPS 206) is still in draft. Build for the three that are final, and design so the others can be added later.
How much bigger are post-quantum certificates?
Substantially. An ML-DSA-44 signature is 2,420 bytes against 72 bytes for ECDSA P-256, and an ML-DSA-87 signature is 4,627 bytes. A full ML-DSA certificate chain runs roughly 14 KB to 18 KB compared with about 586 bytes for an ECDSA chain, which is enough to exceed TCP’s typical 14.5 KB initial congestion window and add a round trip to the handshake.
Do I need to migrate to PQC now if I am not a federal agency?
The federal deadlines are the visible ones, but two things apply to everyone. Harvest-now-decrypt-later means data with a long confidentiality life is already exposed to future decryption. And NIST IR 8547 puts RSA and ECDSA on a path to disallowed status after 2035, which will reach commercial systems through vendors, auditors, and compliance frameworks well before that date.
Where should a team start?
Inventory first. Find every certificate, key, algorithm, and library in use, including in source code. Then use the Playground to test a quantum-safe hierarchy against your real constraints. Then write the roadmap. Doing it in that order is the difference between a plan that survives production and one that does not.
Start in the Lab
Reading about post-quantum cryptography is the cheap part. Running it is where the surprises are, and surprises are much better discovered in a sandbox than in a change window.
Explore the PQC Center of Excellence and spin up your first quantum-safe hierarchy in the PQC Playground.
If you want to see your own environment before you see ours, our free ASN.1 CSR and certificate decoder will tell you what algorithms your current certificates are actually using in about ten seconds. For the fuller picture, the Post-Quantum Cryptography Readiness white paper in the Lab walks through the assessment we run with clients.
When you are ready to turn lab work into a program, our PQC Advisory Services team runs a structured 9-phase migration methodology, backed by ISO/IEC 27001:2022 and SOC 2 certified practices.
