Code that executes in kernel mode shares the kernel's privilege. A bug or compromise in such code can therefore affect the whole system rather than only one ordinary process.

Device drivers translate operating-system operations into device-specific control. In many kernels, drivers and optional kernel modules execute inside kernel space so they can access privileged interfaces directly.

A kernel-resident component becomes part of the system's trusted computing base. It can potentially inspect or modify process memory, intercept system activity or corrupt kernel state.

This is why kernel-level software requires a much stronger trust decision than an ordinary user-space application: adding privileged code expands both the trusted computing base and the possible blast radius of defects.

Some anti-cheat, endpoint-security and monitoring systems use kernel components because adversarial software may also operate below ordinary process boundaries. Greater visibility can improve detection, but it also increases the consequences of vulnerabilities or abuse in that privileged component.

Kernel modules therefore illustrate a general security trade-off: privilege grants enforcement power, but every privileged component becomes another component whose failure can violate the whole boundary.