Principle of Least Privilege

The Principle of Least Privilege (PoLP) is a fundamental security principle stating that any user, process, or system component should have access only to the resources and permissions it needs to perform its legitimate function — and nothing more. In product design terms, this means: network-facing services should not run as root; application processes should not have write access to firmware storage unless performing an update; individual microservices should not have access to data stores they do not need; and default user accounts should not have administrative capabilities. The principle limits the damage an attacker can cause after compromising a single component: if a vulnerable network service runs without privileges, exploiting it gives the attacker limited access to the system rather than full control.

The CRA's Annex I requires manufacturers to minimise the attack surface of their products and implement security controls that limit the impact of compromised components. Least privilege is an essential mechanism for both:

• Attack surface reduction: Processes running with elevated privileges are attractive targets because their compromise yields high-value access. Reducing the number of processes running with elevated permissions reduces the value and impact of each potential compromise.
• Limiting exploit blast radius: A least-privilege architecture ensures that exploiting a vulnerability in a low-privilege network service does not directly give an attacker control over the firmware update mechanism, persistent storage, or other critical system functions.

CRA conformity assessments for higher-risk products will typically examine the privilege architecture of the product's software components as part of evaluating Annex I compliance.

Implementing least privilege in resource-constrained embedded products requires careful design:

• Process isolation: Run each major service (network stack, application, update agent, management interface) as a separate process with a dedicated, minimal-privilege user account.
• Filesystem permissions: Apply strict filesystem permissions — log directories writable by logging processes only, firmware storage writable only by the update process, configuration files readable by application processes but not writable in normal operation.
• Linux capabilities: Use Linux capabilities to grant specific elevated permissions to processes that need them (e.g., CAP_NET_BIND_SERVICE to bind to low-numbered ports) rather than running as root.
• Sandboxing: Use seccomp, AppArmor, or SELinux profiles to restrict the system calls and file accesses available to individual processes.
• No default root shells: Remote management interfaces (SSH, web console) should not provide root access by default — use sudo with explicit command whitelisting for administrative operations.

The threat model required by CRA Annex I should explicitly analyse privilege escalation paths. Key questions in a threat model for least privilege:

• What is the lowest-privilege entry point accessible to an unauthenticated network attacker?
• How many privilege escalation steps are required to reach critical functions (firmware write, key access, data exfiltration)?
• Are there any processes running at unnecessarily elevated privilege that could be downgraded?
• What is the attack chain from initial access to full device control?

Penetration testing should specifically target privilege escalation paths — exploiting a low-severity vulnerability in a network service to achieve privilege escalation to root is a common attack pattern that least privilege is designed to block. CVD researchers frequently report privilege escalation vulnerabilities, and manufacturers should treat them seriously even when the initial access vector requires low-severity exploitation.