CyberForte
0/32 guides done, see your progress

Home Secure by Design and Default Playbook 2

Playbook 2 of 22 · Secure by Design · Architectural Foundations

Least privilege

Give every person and program only the keys they need, only for as long as they need them.

Architectural FoundationsSecure by Design
CyberForte's summary · not ENISA text

In plain words

Least privilege is the hotel key card idea. Guests open their own room, cleaners open the floors they clean, and only the manager has the master key. Nobody gets the master key "just in case".

In your product this means each user role and each service gets the smallest set of permissions that still lets it do its job. Admin rights are personal, protected with multi-factor login, and handed out for a short time when needed. If something is broken into, the damage stays small.

Picture this: A support engineer needs to read a customer's settings, not delete their account. Give them read access, and make delete a separate, logged, time-limited step.

Your turn

Practical checklist

A short, practical version for small teams, written by CyberForte from the ENISA playbook. The full ENISA checklist, evidence list and release gate are in the original text below. Your ticks are saved only in this browser.

Original text · unchanged

The full ENISA playbook

Source: ENISA Secure by Design and Default Playbooks, 02-least-privilege.md, European Union Agency for Cybersecurity (ENISA), licensed under CC BY 4.0. Reproduced word for word; only converted from Markdown to this page.

Least privilege

Principle

(secure by design)

Every user, service and process operates with the feasible minimum permissions needed to do its job – no more and for no longer than necessary.

Objective

Reduces unauthorised access, limits blast radius, blocks lateral movement and prevents permission creep.

Checklist

Define minimum viable permissions for each role/service

  • List key roles (user, support, admin) and key services (API, provisioning, updates).
  • For each, define allowed actions (read/write/admin) and resources (APIs, tables, buckets).

Use unique identities (no shared admin)

  • One identity per service (service account/workload identity) , applicable to both web services and services running on a device.
  • No shared admin users/keys; separate dev/test/prod identities.

Default-deny and explicit allow lists

  • Deny by default; allow only required API methods, data access and network paths.
  • Restrict service-to-service access to specific interfaces.

Time-bound admin access (JIT) + attribution

  • Named accounts + MFA for admins (all human users if possible).
  • Temporary elevation for privileged actions; break-glass is separate and monitored.

Automate privilege hygiene

  • Monthly (or at each release), flag broad privileges and unused permissions/tokens; remove or time-limit exceptions.

Minimum evidence

  • Access model exists: for example, a short table “Role/Service, allowed actions, resources” stored in repo/wiki and kept current.
  • No shared admin: IAM inventory shows unique service identities; no reused production admin keys.
  • Deny works: automated negative tests prove unauthorised API/data access is blocked for each critical service.
  • Admins are accountable: logs show who performed privileged actions; elevation expires automatically.
  • Creep is controlled: recurring report flags unused/broad permissions; removals/exceptions are tracked, with owner and expiry.

Release gate

  • [ ] Unique service identities; no shared production admin keys
  • [ ] Default-deny posture; only required paths enabled
  • [ ] Admin access uses MFA and is time bound and logged
  • [ ] Automated authorisation tests run verifying correct access restrictions for critical privileged functions
  • [ ] Privilege review run; exceptions owned and time limited
↑ ↓ to moveEnter to openEsc to close