TL;DR: A hybrid X25519MLKEM768 key exchange working in a preview PQC environment was shown in Apache tests on AlmaLinux 10, according to Cybertrust Japan, while also using an ECDSA self-signed certificate with correct CA:FALSE constraints to avoid certificate misuse. The practical issue is not whether PQC exists, but how teams prepare authentication and TLS estates for harvest-now, decrypt-later risk before the transition becomes mandatory.
At a glance
What this is: This is a PQC test of Apache on AlmaLinux 10 that combines hybrid key exchange with certificate handling checks and surfaces the operational relevance of HNDL risk.
Why it matters: It matters because TLS and certificate teams need to treat post-quantum readiness as a governance and migration problem, not just a cryptography experiment, especially where long-lived data is at stake.
Context
Post-quantum testing is becoming a practical governance issue for TLS teams because the transition affects key exchange, certificate validation, and the assumptions built into current trust stores. In this case, the article uses Apache on AlmaLinux 10 to show how a preview PQC environment can be exercised without waiting for production deadlines, while still exposing how easy it is to mis-handle certificate constraints.
For identity and access teams, the intersection is real even though the article is not about IAM in the narrow sense. TLS certificates are machine identities, and the move toward hybrid and post-quantum algorithms changes how those identities are issued, constrained, validated, and eventually retired. The starting position is typical of early PQC work: technically sound in a lab, but not yet a full operational model.
Key questions
Q: How should teams prioritise PQC migration for TLS traffic?
A: Start with traffic that must remain confidential for the longest period, because harvest-now, decrypt-later risk depends on data lifespan as much as algorithm strength. Prioritise regulated records, archived sessions, and any service whose secrets or payloads will still matter after cryptographic standards change. That sequence reduces exposure before full platform migration is complete.
Q: Why do machine identities matter in post-quantum cryptography planning?
A: Because machine identities often hold the certificates and keys that actually secure business systems. If teams ignore service accounts, API keys, SSH keys, and code-signing certificates, they miss the assets most likely to block migration or carry hidden dependencies into the quantum-safe transition.
Q: What breaks when certificate constraints are handled loosely during PQC pilots?
A: The pilot can still appear functional while the certificate’s role is misrepresented, especially if basicConstraints and related X.509 fields are wrong or missing. That creates trust ambiguity and can hide whether the certificate is acting as a server credential or being treated like a CA. The failure is governance drift, not just a validation error.
Q: How do TLS teams know if they are ready for a hybrid PQC rollout?
A: Readiness shows up when the environment can negotiate hybrid exchanges, validate certificate roles correctly, and support the needed libraries and policy settings without manual exceptions. If those elements are only working in a one-off lab build, the organisation is still in proof-of-concept mode. Operational readiness means repeatable configuration across the actual estate.
Technical breakdown
How hybrid X25519MLKEM768 key exchange changes TLS testing
Hybrid key exchange combines a classical algorithm such as X25519 with a post-quantum mechanism such as ML-KEM768 so that both sides contribute to session establishment. The practical value in a preview environment is resilience during transition, because the classical component preserves compatibility while the PQC component starts to address future cryptanalytic risk. That does not make the channel magically post-quantum safe in every sense, but it does let operators validate toolchains, libraries, and browser support before mandatory migration pressures arrive.
Practical implication: Test hybrid cipher negotiation in controlled environments before relying on it for production TLS traffic.
Why CA:FALSE matters in post-quantum certificate handling
A server certificate is only safe when its intended role is explicit. The basicConstraints extension with CA:FALSE tells relying parties that the certificate should authenticate a server, not issue other certificates. In lab work, that distinction matters because a self-signed certificate without the correct constraint can look structurally similar to a certification authority certificate, which creates a governance error even if the cryptography is sound. PQC does not remove the need for ordinary certificate hygiene; it raises the cost of getting those details wrong because the surrounding ecosystem is already changing.
Practical implication: Verify basicConstraints and other X.509 extensions as part of every PQC pilot, not as an afterthought.
How harvest-now, decrypt-later risk changes the TLS timeline
Harvest-now, decrypt-later risk means encrypted traffic can be captured today and broken later if the session material or protected data remains valuable long enough. That shifts the issue from abstract cryptographic strength to data lifespan, interception likelihood, and transition timing. For long-lived records, archived sessions, and regulated communications, the exposure window can extend well beyond the life of any single server implementation. TLS teams therefore have to think in terms of business retention, not only protocol correctness.
Practical implication: Prioritise PQC migration for traffic whose confidentiality must survive long retention periods.
NHI Mgmt Group analysis
HNDL readiness is now a data-lifecycle problem, not a crypto curiosity: the core question is whether sensitive traffic will still matter when decryption capabilities improve. That makes retention policy, traffic classification, and migration sequencing part of cryptographic governance. Practitioners should treat long-lived secrets and long-lived ciphertext as the same problem class.
Machine identities sit at the center of PQC transition work: server certificates, trust anchors, and automated issuance pipelines are the control points that decide whether hybrid cryptography is trustworthy in practice. The article shows why certificate lifecycle governance, not just algorithm selection, determines whether new TLS modes can be adopted safely. Practitioners should inventory certificate-bearing workloads first.
Preview deployments are valuable because they reveal hidden dependency debt: browser support, package availability, policy configuration, and certificate constraints all become visible before production urgency sets in. That matters because migration failures usually appear in integration layers, not in the cryptographic primitive itself. Practitioners should use pilots to expose operational friction early.
Post-quantum transition exposes the difference between theoretical support and governed deployment: a stack can technically negotiate a hybrid exchange and still be unsafe if certificate usage, trust scope, or lifecycle controls are ambiguous. The named concept here is HNDL exposure window, the period during which encrypted material remains valuable enough to justify capture now and decryption later. Practitioners should shorten that window with asset prioritisation.
The real governance issue is sequencing: organisations cannot wait for full PQC standardisation before preparing the identity infrastructure that carries TLS trust. That means machine identity management, certificate policies, and crypto agility planning need to move together. Practitioners should align TLS migration with identity governance, not treat it as a separate engineering track.
What this signals
HNDL exposure window: organisations should classify TLS traffic by how long its confidentiality must survive, then move the longest-lived flows to the front of the PQC queue. That is a governance decision as much as a cryptographic one, because retention, archive value, and regulatory exposure all shape the real risk horizon.
PQC pilots expose more than algorithm compatibility. They reveal whether certificate policy, automation, and trust-store management can support a migration without creating new ambiguity around machine identity.
The practical lesson for security architects is to treat post-quantum readiness as a dependency chain that starts with machine identity inventory and ends with crypto agility in production.
For practitioners
- Map long-lived traffic first Identify TLS-protected data flows whose confidentiality must survive years, not months, and prioritise them for post-quantum transition planning.
- Audit certificate-bearing machine identities Inventory server certificates, CA relationships, and automation paths so you know which workloads depend on machine identity trust decisions.
- Validate hybrid negotiation in a lab Test X25519MLKEM768 and similar hybrid modes against your actual browser, library, and policy stack before any production rollout.
- Enforce certificate constraint hygiene Check basicConstraints, SANs, and issuance roles on every test certificate so a pilot does not create false confidence in trust behaviour.
- Create a crypto-agility migration sequence Link PQC planning to certificate lifecycle, trust store updates, and retirement of legacy assumptions so the transition can be governed end to end.
Key takeaways
- PQC testing in TLS is no longer just about algorithm support, because the real risk is how long encrypted material remains valuable to an attacker.
- The article shows that machine identity controls, especially certificate constraints and issuance roles, are part of post-quantum readiness.
- Teams should prioritise long-lived traffic and governed certificate estates first, then use lab pilots to surface dependency debt before production migration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-57 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | HNDL risk is driven by long-lived encrypted material and certificates that outlast today's crypto assumptions. |
| NHI-02 — Secret Leakage | Certificate keys and TLS materials become high-value secrets when post-quantum risk extends their lifetime. | |
| Recommendation — Track long-lived machine credentials and protected traffic so PQC migration starts with the highest-retention assets. Harden storage and handling of TLS private keys and certificate materials across the migration window. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article is fundamentally about cryptographic transition, key lifecycle, and the retirement of legacy assumptions. |
| Recommendation — Plan key lifecycle changes so algorithm migration, rotation, and retirement stay coordinated. | ||
| NIST CSF 2.0 | PR.DS-10 — Confidentiality | PQC readiness is about preserving confidentiality over time as decryption capabilities evolve. |
| Recommendation — Classify traffic by confidentiality duration and protect the longest-lived data first. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Harvest-now, decrypt-later is an information-theft pattern that maps to captured data used later. |
| Recommendation — Model intercepted encrypted traffic as future exfiltration risk and prioritise its protection accordingly. | ||
Key terms
- Hybrid Key Exchange: A transitional cryptographic setup that supports both classical and post-quantum key exchange during session negotiation. It reduces compatibility risk while improving resilience, but it is not a final endpoint because the surrounding certificate and identity estate may still rely on quantum-vulnerable components.
- Harvest now, decrypt later: An attacker strategy where encrypted traffic or stored data is collected today and decrypted later when better computing power becomes available. It matters to NHI governance because machine identities often protect the data paths and secrets most worth preserving over time.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Certificate Basic Constraints: Basic constraints are an X.509 extension that declares whether a certificate may act as a certificate authority. Setting CA:FALSE on a server certificate prevents it from being treated as a CA credential and helps preserve the trust boundary between server authentication and certificate issuance.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that must carry them into production.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org