AlmaLinux 10.1 shows PQC TLS is now practical for enterprises

At a glance

What this is: This is an independent technical test of PQC support in AlmaLinux 10.1, showing that TLS key exchange and PQC signing workflows can be verified on a standard install.

Why it matters: It matters because cryptographic agility, certificate handling, and workload identity transport will eventually affect IAM, NHI, and service-to-service trust boundaries even when the immediate topic is platform crypto.

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.

👉 Read Cybertrust Japan's blog on PQC TLS verification in AlmaLinux 10.1

Context

Post-quantum cryptography is about making encryption and signatures resilient to future cryptanalytic advances, but the practical problem today is compatibility. Security teams need proof that new algorithm suites can work across operating systems, TLS stacks, application servers, and certificate workflows without breaking service availability. In mixed environments, that matters directly for workload identity, mutual TLS, and machine-to-machine trust.

AlmaLinux 10.1 is used here as a test vehicle for PQC readiness, with the article showing OpenSSL 3.5 supporting ML-KEM and ML-DSA in the default crypto policy path. For identity teams, the bridge is simple: when transport security changes, the trust fabric around service accounts, certificates, and automated connections changes with it. That makes cryptographic change management part of identity governance, not just platform maintenance.

Key questions

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. Treat fallback behaviour as a defect, because silent downgrade can hide incomplete rollout and create false confidence in compatibility.

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. When the cryptographic algorithms behind those controls change, teams must revalidate issuance, renewal, rotation, and trust distribution. Without that, a successful cryptographic upgrade can still leave workload identity brittle or ungoverned.

Q: What do teams get wrong about testing post-quantum cryptography?

A: They often test algorithm availability instead of end-to-end trust. A library can expose PQC primitives while proxies, applications, or automation still assume older key types. Real validation means checking negotiation, logging, certificate workflows, and failure modes across the full service chain.

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.

Technical breakdown

OpenSSL 3.5 and default PQC algorithm support

The article shows that OpenSSL 3.5 can expose post-quantum algorithms through the system crypto stack without requiring a separate experimental toolchain. That matters because PQC readiness is not only a compiler or library question, it is a packaging and policy question. If the crypto policy, OpenSSL build, and application expectations align, algorithms such as ML-DSA become visible to standard command-line and service workflows. The practical test is whether the platform can negotiate or use these algorithms in a way that downstream services can consume predictably.

Practical implication: validate PQC support in the same build and policy path your production services actually use, not in an isolated lab image.

TLS key exchange verification in a mixed crypto estate

TLS is where cryptographic transition becomes operational. The article demonstrates that key exchange and signature support can be checked from the system state, which is important because teams rarely move from RSA and elliptic-curve schemes to PQC in a single step. Mixed estates will need transitional periods where classical and post-quantum algorithms coexist. That creates compatibility risks in proxies, load balancers, application frameworks, and client libraries, especially where defaults differ across versions or distributions. The real technical challenge is proving negotiated trust end to end.

Practical implication: inventory TLS termination points and test negotiated cipher and signature paths before you introduce PQC into shared environments.

PQC and the identity layer for services and workloads

Although the article is about cryptography, the identity consequence is workload trust. Certificates, signing keys, and TLS-authenticated service connections are identity mechanisms for non-human systems, so any shift in key algorithms affects machine identity lifecycle management. This is where cryptographic agility intersects with NHI governance: key generation, renewal, rotation, and trust store updates all need to remain auditable when algorithm families change. If automation assumes a fixed key type, PQC adoption can expose hidden dependencies in certificate issuance pipelines and service authentication code.

Practical implication: map PQC migration to workload identity inventory, including certificate authorities, issuing workflows, and rotation automation.

NHI Mgmt Group analysis

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.

PQC readiness is mainly a validation problem. The article shows that support can exist in the stack without being operationally proven across real workloads. That gap is where outages, silent fallback, and trust failures emerge, especially in estates with proxies, legacy clients, and mixed certificate tooling. Practitioners should focus on where the system negotiates trust, not only which algorithms are theoretically available.

Algorithm agility is the named concept this topic exposes. A platform can support new cryptography only if policy, libraries, applications, and automation can change together. Without that agility, teams will treat PQC as a one-time upgrade instead of an ongoing lifecycle capability. Practitioners should align crypto change control with identity and certificate lifecycle management.

Post-quantum adoption will surface hidden dependency debt across service estates. Packages, providers, and command-line tools may expose support, but downstream services often assume older key types or provider names. That creates a governance problem for platform teams and identity teams alike because change visibility is incomplete until the full trust chain is tested. Practitioners should expect migration effort to sit in integration points, not only in cryptographic libraries.

For NHIs, the important question is whether automated trust can survive algorithm churn. Service accounts, certificates, and workload tokens depend on predictable key handling. When those flows move to PQC-capable libraries, any weakness in inventory, renewal, or offboarding becomes harder to detect because the environment will look modern while still carrying legacy dependency risk. Practitioners should use PQC testing to expose weak NHI lifecycle controls.

What this signals

Algorithm agility will become a practical control objective for security programmes that rely on workload identity. The immediate risk is not quantum breakage, it is brittle migration paths that expose hidden dependency debt in TLS, certificate automation, and service authentication. Teams that already struggle with NHI inventory and lifecycle discipline will find PQC change harder to manage unless they tie it to asset, certificate, and trust-path visibility.

Cryptographic change management should be treated as part of identity lifecycle governance. If certificates and machine trust are not tracked with the same discipline as human access, PQC rollout will surface offboarding gaps, renewal gaps, and unmanaged service dependencies. The operational answer is to bring cryptographic transitions into the same change windows and control evidence model used for other identity-critical updates.

Teams should expect the hardest work to sit at integration boundaries rather than in cryptographic libraries themselves. That means validating gateways, mesh components, CA workflows, and application defaults together, then documenting where algorithm choices are enforced, inherited, or overridden.

For practitioners

• 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. Do not rely on isolated lab confirmation if your real estate includes proxies, sidecars, or legacy clients.
• 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. Prioritise the paths that support workload identity and internal machine-to-machine authentication.
• 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. Log and alert on fallback so you can see where compatibility is masking incomplete rollout.
• Tie crypto migration to certificate lifecycle controls Update renewal, rotation, and issuance workflows so PQC changes do not break certificate automation. Include issuing CA readiness, trust store updates, and any hardcoded algorithm assumptions in application code.

Key takeaways

• The article shows that PQC support is no longer theoretical, but operational proof is still the real test.
• The scale of the challenge sits in integration points, where TLS, certificates, and automation have to work together without silent fallback.
• Security teams should align PQC migration with workload identity inventory, certificate lifecycle controls, and end-to-end negotiation testing.

Key terms

• Post-Quantum Cryptography: Cryptographic algorithms designed to resist attacks from future quantum computers. In practice, PQC is introduced to preserve confidentiality and signature trust when current public-key schemes may become weaker over time. The migration challenge is compatibility, not just mathematical strength.
• Algorithm Agility: The ability to change cryptographic algorithms without rewriting applications or breaking service trust. It depends on libraries, policy layers, certificate tooling, and automation all supporting change at the same time. Without agility, cryptographic upgrades become risky, slow, and operationally fragile.
• Workload Identity: The identity a service, application, or automated process uses to authenticate to other systems. It is commonly expressed through certificates, keys, tokens, and TLS trust relationships. Cryptographic changes matter here because the authentication mechanism is part of the identity lifecycle.
• TLS Key Exchange: The process that allows two systems to establish a secure session and agree on encryption keys. For security teams, it is a core trust mechanism for service-to-service communication. PQC adoption affects this layer directly because the supported algorithms determine how session trust is established.

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

👉 Cybertrust Japan's full post includes the command outputs and verification steps for PQC testing

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course covers NHI governance, workload identity security, and secrets management through the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity controls to operational risk across modern security programmes.