PQC testing in Apache on AlmaLinux 10 highlights HNDL risk

At a glance

What this is: This is a practical test of post-quantum TLS key exchange in Apache on AlmaLinux 10, with a key finding that hybrid X25519MLKEM768 can be exercised in a preview policy environment alongside conventional certificate handling.

Why it matters: It matters because TLS migration to PQC affects certificate lifecycle, workload trust, and long-lived service identities that IAM and security teams already struggle to inventory and rotate.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Cybertrust Japan's Apache and AlmaLinux 10 PQC testing notes

Context

Post-quantum cryptography changes the trust assumptions behind TLS, not just the cipher suite in use. For identity and platform teams, the concern is less about a lab test passing and more about how certificate issuance, workload authentication, and service-to-service trust will behave when hybrid algorithms become the norm in production. The primary keyword here is PQC, and the migration question is already an identity governance question as much as a cryptography one.

This article is a vendor-authored test of Apache on AlmaLinux 10 using a preview PQC policy and a hybrid key exchange. That makes it useful as an operational signal, but not as a production guide. The broader lesson is that organisations need to understand which certificates, service accounts, and automated clients will be affected by cryptographic transition before HNDL risk accumulates.

For identity programmes, the interesting boundary is where TLS, certificate management, and machine identity meet. When cryptographic posture changes, the operational burden lands on inventory, rotation, issuance, and offboarding processes that are already weak in many environments.

Key questions

Q: What breaks when PQC is introduced without a full certificate and client inventory?

A: The rollout usually fails at compatibility and trust boundaries, not at the algorithm level. Some clients cannot negotiate hybrid suites, some servers still assume legacy policy, and certificate roles can be misclassified. Without inventory, teams end up debugging outages and trust failures while missing the larger governance issue: machine identities were never mapped to begin with.

Q: Why does harvest-now, decrypt-later risk change TLS migration priorities?

A: Because the threat is time-shifted. Attackers can capture encrypted traffic now and wait for future cryptographic advances to make it readable later. That means the priority is not only protecting current sessions, but also reducing the lifespan of sensitive traffic, tightening key management, and accelerating PQC for systems that hold long-lived data.

Q: How should teams govern machine identities during PQC transition?

A: They should treat certificates, keys, and service endpoints as a governed identity population. That means defining owners, lifecycles, allowed purposes, and rollover paths for each certificate type. PQC transition succeeds when identity governance, not just cryptography, determines what is allowed to present, authenticate, and persist in production.

Q: Who is accountable when a PQC pilot weakens production trust?

A: Accountability should sit with the platform owner that approved the rollout, the security team that defined the policy, and the service owner that accepted the change. If a pilot leaks into production or breaks trust validation, the failure is governance and change control, not just cipher selection.

Technical breakdown

Hybrid key exchange and why X25519MLKEM768 matters

X25519MLKEM768 is a hybrid key exchange that combines a classical elliptic-curve exchange with a post-quantum KEM. The purpose is resilience: if one component is later weakened, the other still helps protect the session. In practice, hybrid modes are transitional controls, not end states. They let operators validate compatibility, performance, and policy handling before fully committing to PQC-only traffic. That matters because TLS ecosystems are sprawling, and every load balancer, reverse proxy, application server, and client library has to agree on supported algorithms before the handshake succeeds.

Practical implication: inventory which TLS endpoints can negotiate hybrid suites before you move any production workloads.

Certificate constraints and the CA:FALSE boundary

The article’s certificate example shows why Basic Constraints still matter in PQC testing. A server certificate must not accidentally advertise CA capabilities, because that would blur the boundary between an end-entity identity and an issuing authority. In the test, adding the explicit CA:FALSE constraint ensures the certificate is treated as a TLS server certificate rather than a certification authority certificate. That distinction is essential in identity governance because cryptographic agility does not remove the need to classify trust roles correctly. The same lifecycle discipline still applies: who can issue, who can present, and what each certificate is allowed to assert.

Practical implication: validate certificate profiles and constraints as part of your machine identity governance workflow.

Preview policies, test flags, and production readiness gaps

The use of a preview crypto policy and a TEST-PQ subpolicy shows that PQC readiness is currently being exercised through staged policy controls rather than broad default enablement. That is a sensible approach, but it also means the real challenge sits in operational consistency. If one environment accepts a hybrid policy and another does not, teams get fragmented behaviour across clients, servers, and automation pipelines. For security and IAM teams, this is the same kind of readiness problem seen in other machine identity transitions: policy must be versioned, rollout must be controlled, and exceptions must be visible.

Practical implication: treat PQC adoption as a controlled policy rollout, not as a single cryptographic switch.

NHI Mgmt Group analysis

PQC migration is now a machine identity governance problem, not just a cryptography upgrade. Hybrid TLS can reduce long-term exposure, but the real control surface is the certificate and workload estate that has to support it. Teams that cannot inventory service identities, certificate profiles, and client compatibility will turn a cryptography programme into an operational exception factory. The practitioner conclusion is simple: treat PQC as part of identity lifecycle governance.

HNDL risk makes delayed action a governance failure, not a technical preference. Harvest-now, decrypt-later attacks only need traffic interception today and patience tomorrow. That shifts the security question from whether current TLS is acceptable to whether data retention, key lifetimes, and service identity duration match the confidentiality horizon of the data being protected. The practitioner conclusion is to align cryptographic transition plans with data sensitivity and retention periods.

CA:FALSE discipline remains essential even in PQC pilots. New algorithms do not excuse weak certificate classification. If an end-entity certificate can be mistaken for an issuing authority, the trust model collapses before PQC even enters the picture. This is where identity governance and cryptographic governance overlap directly: certificate purpose, issuance authority, and lifecycle controls must stay explicit. The practitioner conclusion is to keep trust-role separation visible in every test and rollout.

PQC readiness exposes the same control gaps that machine identity programmes already face. Policy drift, inconsistent rollout, and incomplete inventory are the likely blockers, not the mathematics of ML-KEM. That is why the field should stop treating PQC as a standalone specialist track and instead map it into existing IAM, PAM, and NHI governance. The practitioner conclusion is to fold PQC work into the same operational ownership model used for service accounts and certificates.

What this signals

PQC will expose machine identity debt. Teams that already lack clean inventory of certificates, service accounts, and automated trust paths will find cryptographic transition harder than the cryptography itself. The practical response is to fold PQC planning into identity lifecycle work, including ownership, renewal, revocation, and service-to-service trust mapping.

For programmes already pursuing zero trust, PQC makes the same point more concrete. You cannot continuously verify what you cannot classify, and you cannot safely rotate what you have not inventoried. That is why cryptographic agility should be planned alongside machine identity governance rather than treated as a separate infrastructure task.

The strongest forward signal is that identity teams will increasingly need to own the trust metadata around certificates, not just the secrets behind them. That means the security programme should be ready to link certificate purpose, endpoint identity, and policy state in the same operational view.

For practitioners

• Map hybrid TLS support across the estate Identify which web servers, reverse proxies, libraries, and managed clients can negotiate hybrid key exchange today, then record where fallback behaviour exists so you can plan staged adoption.
• Classify certificates by trust role Separate server, client, and CA certificates in your inventory, and verify Basic Constraints and intended usage so that end-entity identities cannot be confused with issuing authorities.
• Tie PQC rollout to data retention and confidentiality horizons Prioritise services handling long-lived sensitive data, because HNDL risk increases when intercepted traffic may remain valuable for years after collection.
• Roll out preview policies in controlled rings Use policy rings or environment tiers for cryptographic transition testing, and keep exception handling visible so that TEST-PQ style settings do not leak into production unnoticed.

Key takeaways

• PQC adoption in TLS is as much about identity governance as it is about cryptographic algorithms.
• Hybrid key exchange can reduce transition risk, but it does not solve inventory, classification, or lifecycle gaps in machine identity estates.
• Teams should prioritise certificate governance, client compatibility, and HNDL exposure together, or the migration will stall in production exceptions.

Key terms

• Post-Quantum Cryptography: Cryptographic algorithms designed to resist attacks from a future quantum computer. In practice, PQC is a migration programme, not a single algorithm choice. It affects TLS, certificates, key lifecycle, and the operational systems that authenticate services and users.
• 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 attack pattern where encrypted traffic is intercepted and stored today for decryption in the future when stronger computational capability becomes available. The risk is especially relevant for long-lived sensitive data and for systems whose traffic may remain valuable for years.
• Basic Constraints: A certificate extension that declares whether a certificate is allowed to act as a certification authority. In identity governance, this field separates end-entity certificates from issuing authorities, preventing trust confusion and limiting the blast radius of misissued certificates.

What's in the full article

Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:

• Exact Apache and mod_ssl configuration changes used to exercise hybrid key exchange in AlmaLinux 10.
• Step-by-step certificate generation commands, including the ECDSA key and CA:FALSE extension handling.
• Environment-specific validation steps for confirming that X25519MLKEM768 negotiated successfully in a browser session.
• R&D notes on how the test environment fits into the broader PQC preview policy approach.

👉 The full Cybertrust Japan post shows the Apache configuration, certificate generation, and browser verification steps in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle fundamentals. It helps practitioners connect identity controls to broader security programmes that must now absorb PQC transition work.