Sectigo announced Private PQC on April 14, a feature inside Sectigo Certificate Manager that issues ML-DSA-signed certificates from a private CA. Supported algorithms are ML-DSA-44, ML-DSA-65, and ML-DSA-87. Certificates flow through the existing SCM workflow for approvals, auditing, renewal, and revocation. The signing material lives inside Sectigo infrastructure behind a virtual HSM.
The engineering is solid, and the feature is a genuinely useful on-ramp for teams that want to begin running ML-DSA material through their certificate lifecycle before committing it to public-facing PKI. This post is aimed at the next question a CISO or architect asks when they read an announcement like this: which part of our PQC threat model does it cover, and what layers still need attention.
ML-DSA and ML-KEM address different threat models
These are two of the four NIST PQC standards and they defend against different things, so putting them side by side in a migration plan is worth doing once and reusing.
ML-DSA replaces RSA and ECDSA in the certificate signing chain. It protects authentication against a future adversary capable of forging signatures. That matters for long-lived signed artifacts, code signing, document attestations, and certificate chains that need to remain trustworthy past the arrival of a cryptographically relevant quantum computer.
ML-KEM replaces ECDH and RSA-based key establishment in the TLS handshake. It protects the session key against harvest-now-decrypt-later. HNDL is the scenario where an adversary captures ciphertext today, stores it, and recovers the symmetric session key years from now when a CRQC breaks the key exchange. Signature authentication has no bearing on this path. An ML-DSA-signed certificate authenticates the server to the client. It does not change which key the two parties derive or whether that key is recoverable from a captured handshake.
Private PQC ships ML-DSA. A team deploying it gains quantum-safe certificate authentication in their internal PKI. HNDL protection for TLS traffic comes from enabling ML-KEM (typically hybrid ML-KEM with a classical partner) in the handshake, which is a separate deployment step.
Both belong on the migration plan. Knowing which layer each covers keeps scope clear.
What “Private” means in the product name
Private PQC issues certificates from a private CA: they chain to a root trusted only inside the customer’s own environment. Those certificates are excellent for internal services, code signing, CI/CD artifacts, and any workflow where the customer controls both ends of the trust chain.
Public-facing endpoints on the internet continue to use certificates from publicly trusted CAs. As of today, those public CAs have not yet begun issuing ML-DSA certificates at scale, and browsers and ecosystem clients aren’t widely configured to trust them. That’s expected to change over the next few years, and Sectigo’s private-side work is a reasonable place to build operational muscle before the public side is ready.
A team can productively use Private PQC now for internal PKI while holding their public TLS configuration on classical certificates. The migration plan then tracks both timelines separately.
Mapping capabilities to layers helps avoid overscoping
PQC work lands at several layers, and each vendor tends to announce at the layer their product occupies. Keeping a simple mental map of which announcement fits which layer saves a lot of meeting time.
Microsoft SymCrypt adding ML-KEM support is a crypto-library fact; whether a specific Microsoft product like SQL Server negotiates ML-KEM in its handshake is a separate product-level decision. Cloudflare client-to-edge PQC figures are one layer; origin-to-Cloudflare PQC is another. Microsoft’s CPM framework itself splits these cleanly into code, network, runtime, and storage domains.
A CA issuing ML-DSA certificates is one layer. A server presenting one of those certificates in a live handshake is the next layer. A client negotiating a hybrid ML-KEM key exchange against that server is the layer after. Each capability is real at the layer where it lives. HNDL exposure specifically comes down to which key exchange the server and client end up selecting.
What a handshake scan contributes to this planning
Once a team has announcements sorted by layer, the practical question is what their own infrastructure is doing today. Scanning TLS handshakes answers that for the network layer: what the server offered, what got selected, and what signed the certificate chain. A server presenting a Sectigo Private PQC certificate would show ML-DSA-44, ML-DSA-65, or ML-DSA-87 in the signature algorithm field. The key exchange group field reports whatever was actually negotiated, which for most deployments today remains an ECDH curve.
Repeated scans across a site fleet give the trajectory: whether a deployment is moving toward hybrid PQC key exchange, stable on a classical key exchange with a new signature algorithm layered on top, or moving in some other direction. That picture complements the vendor announcements with data from your own stack.
Planning through the funding window
Sectigo’s press release cites a figure that 90 percent of organizations expect to fund PQC initiatives in the next twelve months. Procurement pressure, the Google and Cloudflare 2029 deadlines, BSI TR-02102 guidance, and DORA all point the same way. More PQC-labeled features will land through this window. Some address the certificate layer, some address the handshake layer, some update underlying crypto libraries without changing negotiation behavior. All three kinds of work are legitimate, and a mature program includes all three.
A layered map of your estate (what certificates you issue, what your servers negotiate, what your clients prefer) lets you match each vendor announcement to the right line item on your plan. That’s the check that keeps a PQC program proportionate to the threat surface it’s actually addressing, and makes each funding dollar easier to defend.