Fix Secure Boot Blocking Kernel Modules With MOK Enrollment (October 2026)

I have hit this wall before. You install a fresh Linux distro, reboot, and the system tells you that Secure Boot is blocking a third-party kernel module like NVIDIA or VirtualBox. Your screen fills with red text about “module verification failed” or “Secure Boot violation,” and the fix is not as scary as it sounds.

This guide walks through the exact process I use to fix Secure Boot blocking a third-party kernel module with MOK enrollment. MOK stands for Machine Owner Key, and it is the standard Linux mechanism that lets you sign and load your own drivers without turning Secure Boot off.

By the end, you will know what Secure Boot is, why it rejects unsigned modules, how to generate and enroll a MOK key, and what to do when kernel updates break things.

What Is Secure Boot and Why It Blocks Third-Party Modules?

Secure Boot is a UEFI firmware feature that checks every piece of code that runs before your operating system loads. The idea is simple. The firmware keeps a list of trusted signing keys, and anything that boots must carry a valid signature from one of those keys.

Your Linux distribution ships with signed kernels and signed first-party modules, so those always pass. The problem starts when you install a third-party kernel module like the NVIDIA proprietary driver, the VirtualBox host module, or a VMware vmmon and vmnet pair. Those modules are compiled locally or downloaded outside the distro’s signed chain.

When Secure Boot sees a module that is not signed by a trusted key, it refuses to load it. You will usually see something like “module verification failed: signature and/or required key missing” in journalctl -k. That is the firmware protecting you from boot-time rootkits, even though it is also blocking the driver you actually want.

The cleanest fix is not to disable Secure Boot. The fix is to enroll your own Machine Owner Key, sign the module with it, and teach your firmware to trust it.

Understanding MOK (Machine Owner Key)

MOK is short for Machine Owner Key. It is a public and private key pair that you, the owner of the machine, control. The private key lives on your hard drive and lets you sign kernel modules. The public key gets enrolled in your UEFI firmware under a database called MOKlist.

When the Linux kernel loads a module, it checks three keyrings: the platform keyring, the built-in keyring, and the MOK keyring. If a module carries a signature that verifies against any key in any of those rings, the module is allowed to load. Enrolling a MOK key adds your public key to the MOK keyring, which is exactly where you need it.

The shim bootloader handles the MOK enrollment dance at boot time. When you run mokutil --import, shim queues the key for the next reboot and presents the blue “MOK Manager” screen where you confirm enrollment with a one-time password.

This is why MOK exists. It lets the user add trust on demand without giving them the dangerous power to permanently disable Secure Boot.

Prerequisites Before You Start

Before you enroll anything, confirm a few basics so the process goes smoothly.

• You need root access, either through sudo or direct login. MOK operations require elevated privileges.

• Your UEFI firmware must support Secure Boot. Run mokutil --sb-state to confirm it returns “SecureBoot enabled.”

• You need mokutil installed. On Ubuntu and Mint it ships with shim-signed, and on Fedora it is in the shim-unsigned package.

• You need a working keyboard at boot time, since the MOK Manager dialogs are text-based.

Pick a temporary password you will remember. MOK Manager asks for it exactly once on reboot, then the key is enrolled for good. The password only matters during that single enrollment step.

Step-by-Step MOK Enrollment Process

This is the core fix for Secure Boot blocking a third-party kernel module. Follow each step in order, and pay close attention to the reboot step at the end.

Step 1: Install Required Tools (mokutil)

If mokutil is missing, install it now. On Ubuntu, Linux Mint, and Pop!_OS run:

sudo apt install mokutil

On Fedora:

sudo dnf install mokutil

On openSUSE:

sudo zypper install mokutil

Verify the install worked by running mokutil --version.

Step 2: Generate or Import a MOK Key Pair

You need an X.509 key pair. Many installers and helper tools create one automatically. To generate one manually with OpenSSL:

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -out MOK.pem -days 36500 -subj "/CN=Machine Owner Key/" -addext "extendedKeyUsage=codeSigning"

That command writes a private key to MOK.priv and a self-signed certificate to MOK.pem. Guard MOK.priv carefully. Anyone with that file can sign modules as you.

Step 3: Set a One-Time MOK Password

You only need this if your distro installer did not already set one. The FedEx-style flow is sudo update-secureboot-policy --enroll-key, which prompts you for a password and handles import for you.

If you want manual control, use sudo mokutil --import MOK.pem. mokutil will immediately ask you for a one-time password. Type it twice to confirm, and do not forget it. Eight to sixteen characters is the usual range.

Step 4: Import the MOK Public Key

The --import call from the previous step actually places the public key certificate into a pending enrollment state inside the shim variable. The firmware has not trusted it yet. That happens on the next reboot when the MOK Manager runs.

You can confirm the key is queued by running sudo mokutil --list-pending. You should see your certificate fingerprint listed.

Step 5: Reboot and Complete MOK Manager Enrollment

Reboot the machine. After the manufacturer logo, shim takes over and presents a blue MOK Manager screen instead of your usual GRUB menu.

1. Choose “Enroll MOK.”

2. Choose “View key” to confirm the fingerprint matches what mokutil --list-pending showed.

3. Choose “Continue” and then “Enroll.”

4. Type the one-time password you set earlier when prompted.

5. Select “OK” and then “Reboot.”

If you pick “Continue boot” instead of “Enroll MOK,” shim discards the pending enrollment and your module will still be blocked. Always pick “Enroll MOK” for the first enrollment. After this step, the public key is permanent in the MOKlist until you remove it.

How to Sign Kernel Modules with MOK

Enrolling the key is only half the job. The kernel still rejects any module that does not carry a valid signature from your enrolled MOK private key.

Use the kernel signing tool to sign the offending module. Replace vboxdrv.ko with the actual module path if yours is different:

sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 MOK.priv MOK.pem /lib/modules/$(uname -r)/misc/vboxdrv.ko

That one line signs the module using SHA-256 with your MOK key. Repeat for any other unsigned module you need, including the matching vboxnetflt.ko, vboxnetadp.ko, NVIDIA nvidia.ko, or VMware vmmon.ko and vmnet.ko.

Once the module is signed, rebuild its dependency map and try loading it:

sudo depmod && sudo modprobe vboxdrv

If modprobe returns silently, the module is loaded and Secure Boot has accepted it.

Verifying MOK Enrollment Worked

After reboot, you should confirm that the MOK key actually made it into firmware. Run sudo mokutil --list-enrolled and you should see your certificate’s SHA-1 fingerprint and subject.

If the list is empty, your enrollment did not stick. Common causes are boot priority jumping straight to GRUB and skipping shim, or choosing “Continue boot” in the MOK Manager by accident.

You can also verify that a specific module carries a valid signature:

sudo modinfo -F signer /lib/modules/$(uname -r)/misc/vboxdrv.ko

If the signer field is empty, the module is unsigned. If it shows your MOK subject, the kernel will trust it.

Handling Kernel Updates After MOK Enrollment

Here is the catch that trips up a lot of people. Linux distributions rebuild third-party modules through DKMS or akmods every time the kernel version changes. Those rebuilds produce fresh, unsigned .ko files.

The good news is that Fedora and a few other distros ship signed kernels that use a distro-specific MOK, so akmods-spawned modules get auto-resigned in the build process. On Ubuntu and Mint you usually need to resign manually or use a helper script.

I keep a tiny script named resign-modules.sh for this purpose:

#!/bin/bash
KEY="/root/MOK/MOK.priv"
CERT="/root/MOK/MOK.pem"
for mod in $(find /lib/modules/$(uname -r) -name "*.ko"); do
/usr/src/kernels/$(uname -r)/scripts/sign-file sha256 "$KEY" "$CERT" "$mod"
done
depmod -a

Run that after every kernel update and you are back in business without re-enrolling the MOK key itself.

Common MOK Enrollment Errors and Fixes

Even when you follow the steps exactly, things can still go wrong. Here are the four failure modes I see most often in forum threads.

MOK Dialog Does Not Appear on Reboot

This usually means your firmware is jumping straight to GRUB and bypassing shim. Enter your UEFI setup, check the boot order, and make sure the shim file (shimx64.efi) is first.

On some HP and Lenovo machines you have to disable Fast Boot in the firmware setup before shim can pause for the MOK Manager.

Password Not Accepted in MOK Manager

MOK Manager is strict about passwords. Eight characters minimum, sixteen maximum. Avoid special characters that the US keyboard layout in firmware might not recognize, like non-ASCII symbols. If the password fails three times, reboot and try mokutil --import again with a fresh password.

Module Still Blocked After Enrollment

You enrolled the key, but the kernel still refuses to load your module. Check three things.

• Confirm mokutil --list-enrolled shows your certificate.

• Confirm the module is actually signed by inspecting it with sudo modinfo -F signer.

• Make sure you are loading the freshly signed module, not a cached version.

Lost or Forgotten MOK Password

The good news is the password is only needed during the single boot where shim presents the MOK Manager dialog. Once enrollment succeeds, the password is discarded. If you forgot it before completing enrollment, reboot and re-run sudo mokutil --import MOK.pem to set a new one.

MOK Enrollment vs Disabling Secure Boot: A Security Comparison

Some users solve the module problem by disabling Secure Boot in the UEFI setup. That works, but it lowers your boot-time security baseline. Here is how the two options compare.

With MOK enrollment, the firmware still rejects any unsigned module. Only modules you deliberately sign with your private key get loaded. Malware that injects unsigned kernel code at boot still fails. MOK enrollment keeps the chain of trust intact, while still letting you run that NVIDIA driver you paid for.

With Secure Boot disabled, the firmware loads any module the OS asks for. There is no signature check. Anything that can run with root privileges during boot could load a malicious kernel module. For desktop Linux users on a personal machine the practical risk is low, but for a laptop that travels or a workstation handling sensitive data, leaving Secure Boot on with MOK is the stronger choice.

My recommendation is simple. Keep Secure Boot enabled and use MOK unless you have a workflow that genuinely demands disabling it, such as running an unsigned hobby kernel for research.

Distribution-Specific Notes for MOK Enrollment

The core process is the same everywhere, but a few distributions add their own flavor.

Ubuntu and Linux Mint. The installer auto-triggers update-secureboot-policy --enroll-key when it detects a third-party driver like NVIDIA. Most users only see the MOK Manager dialog because of that hook. If you skipped it during install, you can run it any time later.

Fedora. Fedora uses a distro MOK signed by Red Hat, so akmods-built NVIDIA and kmods-built VirtualBox modules get signed automatically at build time. You usually do not need to manually enroll or sign anything as long as you install via the official RPM Fusion kmod packages.

openSUSE. openSUSE ships its own shim and uses a similar flow to Ubuntu. A few community threads report that aggressive kernel updates can occasionally clobber the MOK NVRAM variable, requiring re-enrollment after a BIOS flash. Keep MOK.priv backed up.

Pop!_OS and elementary OS. Both are Ubuntu derivatives and follow the same mokutil flow as Ubuntu.

Frequently Asked Questions

Final Thoughts on MOK and Secure Boot

Secure Boot blocking a third-party kernel module is one of the most common Linux papercuts of 2026, but it has a clean, official fix. Generate a MOK key pair, enroll the public half through mokutil and the shim MOK Manager, and then sign the modules you actually need. Your machine stays protected, and your drivers load on every boot.

Keep MOK.priv and MOK.pem backed up somewhere safe. After a kernel update, resign any module that DKMS rebuilt, and you will rarely have to look at the MOK screen again.