The latest batch of patches for the Linux 7.2 kernel brings a piece that at first glance might seem a detail for insiders, but that actually draws a security perimeter destined to last decades. We are talking about the integration into the IMA (Integrity Measurement Architecture) and EVM (Extended Verification Module) subsystems of support for ML-DSA digital signatures, one of the algorithms selected by NIST to withstand attacks from future quantum computers.

This is not a simple cryptographic extension: it is a precise signal toward long-term protection of data integrity. For those managing on-premise infrastructures where LLM models, weights, and datasets reside on local storage, the arrival of post-quantum verification mechanisms means securing the software and AI supply chain against tampering that today may seem science fiction, but that in a few years will become a concrete attack surface.

What IMA and EVM do (and why ML-DSA makes them more robust)

IMA and EVM are two pillars of integrity control in the Linux kernel. The first calculates hashes of executables and critical data at boot and compares them against expected values; the second extends this verification to extended file attributes, creating a trust chain that covers the entire filesystem. Until now, these checks have relied on signature schemes like RSA or ECDSA, which are vulnerable to a hypothetical quantum computer capable of factoring large numbers or computing discrete logarithms in reasonable time.

ML-DSA (Module-Lattice Digital Signature Algorithm) belongs to the family of lattice-based cryptosystems, considered resistant to quantum attacks. Embedding it into IMA and EVM means that the integrity of a Linux system can now be guaranteed by signatures that remain valid even in a post-quantum scenario. For on-premise deployers of artificial intelligence models, this is not an academic quirk: it is a concrete guarantee that the model running in production – perhaps a large LLM – has not been altered after training or during an update, nor have the reference datasets on which it was fine-tuned.

Sovereignty and the AI supply chain: the on-premise fallout

When a company decides to keep its own inference workloads away from public clouds, it does so for control, latency, and data sovereignty. But a self-hosted environment can become a silent target: an attacker who modifies model checkpoints or introduces backdoors into weights before deployment could operate for months undetected. With IMA and EVM enabled and signed with ML-DSA, every key file in the machine learning pipeline – from containers to serialized models – can be verified at boot, making a software supply chain attack much more difficult.

The transition to post-quantum signatures at the kernel level is a foundational block for organizations that think about TCO over extended time horizons. Models trained today could remain in service for five or ten years; a quantum attack that compromises their integrity during that period would force costly retraining operations or security incidents with impacts far exceeding hardware costs. Equipping oneself with resistant verification tools from the software base – the kernel – eliminates a systemic risk before it even materializes.

Beyond the kernel: implications for those designing local AI infrastructures

The arrival of ML-DSA support in Linux 7.2 does not solve all problems by itself: for the protection to be effective, the system must be carefully configured, keys must be managed securely, and a public key infrastructure (PKI) capable of distributing post-quantum certificates is needed. However, for teams designing on-premise inference clusters, this change shifts the security calculus: alongside a TPM or a secure enclave, IMA/EVM with ML-DSA signatures becomes a tile in a layered defense strategy that protects both sensitive data and the integrity of AI artifacts.

Looking at the broader picture, the Linux kernel’s move is consistent with a general acceleration toward post-quantum cryptography, driven by NIST guidance and the deadlines that many government agencies are setting for migration. Those today evaluating an on-premise LLM deployment – for compliance, confidentiality, or simply to reduce dependence on external vendors – can start considering these technologies as standard components of their trust architecture, rather than as frills for military environments. It is a step toward an AI that is not only trained and served in-house, but also verifiable in every bit, today and tomorrow.