NVIDIA driver with Secure Boot on Ubuntu and RHEL servers: signed modules, DKMS and MOK

What Secure Boot changes for the NVIDIA driver

The NVIDIA driver works with Secure Boot on, as long as its kernel modules are signed with a key the kernel trusts. On Ubuntu, Canonical's precompiled -server modules are signed and need no key of your own; on RHEL 10, Red Hat's precompiled kmod-nvidia-open packages are. With DKMS, from NVIDIA's repository or on RHEL 8 and 9, the modules are signed with a local key that you enrol once as a Machine Owner Key.

The NVIDIA driver is an out-of-tree kernel module, built and shipped separately from the kernel. Under UEFI Secure Boot the kernel checks each module's signature. Ubuntu's server documentation, "NVIDIA drivers installation", puts it plainly: "If your system uses Secure Boot (as most x86 modern systems do), your kernel will require the kernel modules to be signed." Red Hat's RHEL 9 guide to signing kernel modules shows the consequence in its loading table: with Secure Boot enabled, an unsigned module does not load, and neither does a signed one whose public key the system does not trust.

For the RTX PRO Blackwell cards there is a second constraint. NVIDIA states that on Blackwell "you must use the open-source GPU kernel modules", and from R615 the open modules are the only flavour its packages provide, as our guide to NVIDIA driver branches and CUDA versions explains. The signing question is therefore about the open modules on every server we discuss here.

Ubuntu Server documentation "NVIDIA drivers installation"; NVIDIA Driver Installation Guide (updated 23 September 2026), Ubuntu, RHEL and FAQ pages; Red Hat Enterprise Linux 9 documentation on signing kernel modules for Secure Boot; read on 24 October 2026.

Two commands show where a server stands. mokutil --sb-state prints the Secure Boot state, in the words of its manual page "Show SecureBoot State". modinfo nvidia | grep signer shows who signed the module that is installed, the check Red Hat's guide uses for its own example module.

Ubuntu: Canonical's precompiled modules

Ubuntu's documentation describes two driver families. Enterprise Ready Drivers "are recommended on servers and for computing tasks", and "Their packages can be recognized by the -server suffix". It then gives two ways to get the kernel modules under Secure Boot, "mutually exclusive": the precompiled NVIDIA modules for your kernel, or modules you build with the NVIDIA DKMS package after you "enroll your own key to sign the modules". NVIDIA's own installation guide confirms the first route from its side: Canonical "provides signed -server packages that correspond with NVIDIA Datacenter Driver releases". For the second, Ubuntu adds a note: "We don't recommend using the DKMS modules unless you are running a custom kernel for which the prebuilt drivers are not supported", because "the DKMS drivers are not signed with Canonical's key and thus do not support secure boot"; its own DKMS instructions therefore have you enrol a key of your own.

The page also documents the ubuntu-drivers tool, which "will, by default, only install the pre-built, signed drivers which are known to work with Secure Boot". For servers and compute workloads it uses the --gpgpu option: sudo ubuntu-drivers list --gpgpu lists the server drivers for the installed hardware, and sudo ubuntu-drivers install --gpgpu nvidia:<branch>-server installs a chosen branch, followed by sudo apt install nvidia-utils-<branch>-server for the tools.

The precompiled modules come as a metapackage per driver branch and kernel flavour, in Ubuntu's notation linux-modules-nvidia-${DRIVER_BRANCH}${SERVER}-${LINUX_FLAVOUR}, followed by the driver metapackage nvidia-driver-${DRIVER_BRANCH}${SERVER}. For Blackwell the names carry -open as well. Canonical's archive on Launchpad listed these packages on 24 October 2026:

Launchpad API, published binaries in the Ubuntu primary archive for noble amd64, read on 24 October 2026. Full module package names: linux-modules-nvidia-595-server-open-generic and linux-modules-nvidia-580-server-open-generic; both also exist for Ubuntu 26.04 (resolute), kernel 7.0.0-38.

Both driver versions are the releases NVIDIA's security bulletin of 30 September 2026 names as fixed, so Canonical's packages carry the security fix. They do not carry NVIDIA's newest releases: NVIDIA's own list shows 595.112.07 of 22 October 2026 and 580.196.07 of 21 October 2026, which were not in Canonical's archive on the day we looked. Canonical publishes on its own schedule.

Kernel updates follow from the same design. The modules are built for each kernel, and Ubuntu's documentation tells you to check that the package exists for the running kernel, with apt-cache policy and $(uname -r), and, if it is missing, to upgrade to the latest kernel or install the package for the running one. Ubuntu also notes that at a branch's end of life "Canonical will transition you to the next supported driver branch automatically", which an operator who pins a branch should plan for. Fabric Manager, needed only for NVSwitch systems, comes only with the -server packages.

Switching routes later means removing the installed driver first. Ubuntu's documented sequence is apt --purge remove for the branch's packages and apt autoremove, then the installation of the other module type.

We build AI servers to order and install the operating system, drivers, CUDA and a container runtime on request; tell us the distribution, the driver branch and whether Secure Boot must stay on, and our team replies within one business day.

Ubuntu with NVIDIA's repository: DKMS and a MOK key

NVIDIA's own repository serves Ubuntu 22.04, 24.04 and 26.04, and its guide installs the driver with apt install nvidia-open, or for a compute-only server with apt -V install and the packages libnvidia-compute and nvidia-dkms-open. Its version-locking packages, such as nvidia-driver-pinning-580, keep a server on one branch. The modules are built locally by DKMS, so the kernel headers must match: apt install linux-headers-$(uname -r).

Under Secure Boot, a DKMS build is signed with a local key, and that key has to be trusted. NVIDIA's FAQ shows DKMS output in which the "Signing key" is /var/lib/dkms/mok.key and each module, nvidia.ko and the others, is signed during the build; the example is from a Fedora host. Ubuntu's documentation says the NVIDIA DKMS package "may automatically guide you through creating and enrolling a new key for Secure Boot". Enrolment is the Machine Owner Key procedure of the shim boot loader: mokutil --import registers a request "to shim" for a certificate in DER format, protected by a one-time password; at the next boot, the MOK manager asks for that password and enrols the key.

That screen appears before the operating system starts, so on a rack server it needs the BMC's remote console. mokutil --list-new shows the pending request, mokutil --list-enrolled the keys already stored and mokutil --test-key whether a given certificate is enrolled.

DKMS has a second operational point. NVIDIA's FAQ warns that when kernel components are updated without a reboot, "the DKMS framework will sometimes fail to correctly rebuild the NVIDIA kernel module packages", and gives the repair: dkms status, then a build and install for the driver version and kernel. Keep the kernel and its headers in the same update, and check nvidia-smi after each kernel update.

The reason to choose this route is control over the driver version: you install NVIDIA's own packages for the release you choose, independent of when Canonical rebuilds it. The cost is the key management that Canonical's note warns about, on every server.

RHEL: Red Hat-signed modules on RHEL 10, DKMS on 8 and 9

NVIDIA's installation guide, updated on 23 September 2026, describes precompiled kernel modules for Red Hat Enterprise Linux 10. Its list of advantages begins with "UEFI Secure Boot works out of the box via trusted keys already installed in the kernel keyring by Red Hat", followed by "Simpler dependencies: removes kernel-devel, kernel-headers, DKMS and GCC compiler requirements" and no need for EPEL. The guide calls the modules "Red Hat signed" and "provided by Red Hat"; in its example the kmod-nvidia-open package comes from the rhel-10-for-x86_64-extensions-rpms repository, enabled with subscription-manager, and the driver user space from NVIDIA's cuda-rhel10 repository. The install command is dnf install kmod-nvidia-open nvidia-driver nvidia-driver-cuda.

The precompiled route adds one safety catch. A DNF plugin "prevents upgrades to a kernel for which no precompiled driver yet exists" and prints "NVIDIA driver: some kernel packages have been filtered due to missing precompiled modules"; dnf nvidia-plugin reports what it held back. A server therefore stays on its current kernel until Red Hat publishes modules for the new one.

On RHEL 8 and 9 the guide uses DKMS module streams such as nvidia-driver:open-dkms or 580-open, with kernel-devel and kernel-headers for the running kernel and EPEL for DKMS. In February 2025 NVIDIA announced Red Hat-signed open modules for RHEL 9 as a technical preview from RHEL 9.5, which "can now be installed and used without any extra key enrollment configuration"; the current guide limits its precompiled section to RHEL 10. For RHEL 8 and 9 servers under Secure Boot, plan for a MOK key.

Red Hat's documentation for that key is detailed: create an X.509 pair with efikeygen, export the certificate, mokutil --import it, reboot and choose "Enroll MOK" in the MOK manager, then confirm with keyctl list %:.platform that the key is on the platform keyring. Modules are signed with the kernel's sign-file script and SHA-256. Rocky Linux and AlmaLinux have their own pages in NVIDIA's guide.

Protecting the signing key

Once enrolled, a MOK key is trusted by the boot chain and the kernel for every module it signs, not only for the NVIDIA driver. Red Hat's guide asks you to "Apply strong security measures and access policies to guard the contents of your private key", and anyone who has the unencrypted private key can sign modules that your servers will load. A DKMS key generated on each server stays on that server; a company key used across a fleet is easier to audit and more valuable to an attacker, so it belongs in the same protected store as your other code-signing keys. Our guide to securing a GPU server covers the layers below the operating system, BMC and firmware, that Secure Boot itself depends on.

Kubernetes, confidential computing and other cases

On Kubernetes, the GPU Operator normally builds the driver in a container on each node. NVIDIA's page on precompiled driver containers, updated on 14 October 2026, says they "do not require internet access to download Linux kernel" headers and avoid the compile step; images are built for a set of kernel variants, among them generic, nvidia and oracle, and they "do not support NVIDIA vGPU or GPUDirect Storage (GDS)". The page does not say how its modules are signed, so test a node with Secure Boot on before you roll the setting out; our guide to an air-gapped LLM server covers the registry the containers need.

Confidential computing has its own rule. NVIDIA's deployment guide states that "Setting the CC modes for the GPUs is not possible if the host is configured in Secure Boot mode", so Secure Boot is off while the mode is switched during commissioning, as our guide to confidential computing on H200 NVL and RTX PRO 6000 describes. Firmware updates that touch the BIOS can also change Secure Boot settings; our guide to GPU server firmware updates includes the check after each one.

Choosing a route for a fleet

Our summary of the documents cited above, as of 24 October 2026.

For most Ubuntu GPU servers in production, Canonical's signed -server-open packages are the shortest way to keep Secure Boot on: no key to manage, and the R580 and R595 branches with NVIDIA's September security fixes. Teams that need NVIDIA's newest point release, or that pin with NVIDIA's version-locking packages, take the DKMS route, which Canonical recommends only for custom kernels, and plan for key enrolment on each server. On RHEL 10 the precompiled packages are the documented choice. Our comparison of Linux for GPU servers weighs the distributions themselves.

Checks after every kernel or driver update

1. mokutil --sb-state still reports Secure Boot enabled.
2. modinfo nvidia | grep signer names the expected signer.
3. nvidia-smi lists every GPU; a "Driver/library version mismatch" after a driver update means the server has not been rebooted.
4. On DKMS servers, dkms status shows the module built for the running kernel.
5. On RHEL 10, dnf nvidia-plugin shows no kernel held back without reason.
6. DCGM and the kernel log show no new XID messages in the first days, as our XID error code reference describes.

What we supply

You can buy GPU servers from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers to order with two to eight GPUs, assembled and tested before delivery, on one EU contract and invoice with manufacturer warranty on every component, and install the operating system, drivers, CUDA and a container runtime on request. Send us your distribution, kernel policy and driver branch, and we answer with a configuration that matches them.

FAQ