Notifications
Clear all
Topic starter
10/07/2026 9:12 pm
TL;DR: AlmaLinux 10.1’s OpenSSL 3.5 update exposes support for post-quantum cryptography algorithms including ML-KEM and ML-DSA, and the article shows TLS key exchange verification working in practice across a standard installation. The operational question is no longer whether PQC exists, but how quickly teams can prove compatibility across real services.
NHIMG editorial — based on content published by Cybertrust Japan: AlmaLinux 10.1 shows PQC support and TLS key exchange verification
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams introduce PQC without breaking TLS services?
A: Start with a controlled inventory of every TLS termination and certificate issuance point, then test PQC support in the same operating system build, policy set, and client path used in production.
Q: Why does PQC migration affect workload identity and NHI governance?
A: Because certificates, signing keys, and service-to-service TLS are identity controls for non-human systems.
Q: What do teams get wrong about testing post-quantum cryptography?
A: They often test algorithm availability instead of end-to-end trust.
Practitioner guidance
- Validate PQC inside your production crypto path Test OpenSSL, system crypto policies, and service endpoints together on the same distribution build you use in production.
- Inventory TLS termination and signing dependencies Map every place where certificates, key exchange, or signature verification occurs, including load balancers, API gateways, and internal service meshes.
- Check algorithm negotiation for fallback risk Confirm whether services silently fall back to non-PQC algorithms when a client or library cannot negotiate the new path.
What's in the full article
Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step command output showing how AlmaLinux 10.1 exposes PQC algorithms through OpenSSL 3.5
- Exact verification commands for checking policy state, signature algorithms, and ML-DSA key generation
- Observed differences between the newer OpenSSL path and earlier AlmaLinux 10 behaviour
- Practical validation notes for using PQC with Apache httpd and Nginx
👉 Read Cybertrust Japan's blog on PQC TLS verification in AlmaLinux 10.1 →
PQC TLS on AlmaLinux 10.1: what security teams need to test now?
Explore further
10/07/2026 9:35 pm
Cryptographic transition is now an identity governance issue, not just a platform upgrade. TLS, signing, and certificate handling are the control plane for many machine-to-machine relationships. When algorithm support changes, the trust assumptions behind workload identity change with it, so identity teams need to treat crypto migration as part of NHI governance and service authentication planning.
A question worth separating out:
Q: How do you know if PQC readiness is actually working in production?
A: Look for successful negotiation on real services, stable certificate issuance, no unexplained fallback to classical algorithms, and no breakage in automation that depends on signing or TLS. If you cannot observe those signals, the environment may be PQC-capable in theory but not operationally ready.
👉 Read our full editorial: AlmaLinux 10.1 shows PQC TLS is now practical for enterprises
