1 The Principle of Least Privilege
Least privilege states that users and systems should receive only the access necessary to perform their required function. NIST describes it in terms of permitting only the authorised access needed to accomplish assigned organisational tasks, and periodically reviewing those privileges.
A marketing employee probably needs Microsoft 365, Teams, the marketing SharePoint site, a marketing automation platform, and read access to the CRM. They almost certainly don't need Domain Admin, payroll database access, firewall administration, AWS admin, or customer database admin. This sounds obvious — in practice, excessive privileges are extremely common.
Privilege accumulation
An employee starts in technical support and receives support systems, the ticketing system, support SharePoint, VPN, and diagnostic tools. Two years later they move into engineering and receive GitHub, a development AWS account, Jira, the CI/CD platform, and engineering docs — but nobody removes the old support permissions. A year after that they become an engineering manager and gain manager systems, budget systems, and extra production access. They've now accumulated permissions from three different jobs. This is privilege accumulation, also called access creep — and it's a major reason identity lifecycle management (Lesson 4) matters as much as it does.
Least privilege for administrators
This matters most for admins. An IT administrator shouldn't use the same account for reading email and Domain Administration — a company might issue john.smith@company.com for normal work and a separate adm-john.smith for admin tasks. Highly sensitive environments go further still:
The privileged role might exist for just 30 minutes, 1 hour, or 4 hours rather than permanently — an approach known as Just-in-Time (JIT) privileged access.
Standing privileges vs just-in-time access
Traditional model: John is Domain Admin 24 hours a day, 365 days a year. Modern model: John normally has no Domain Admin rights — he requests it, performs MFA, gets approval, has it activated for 1 hour, and it expires automatically. Reducing permanent (standing) privilege dramatically reduces what a compromised account can be abused for, since most of the time there's simply nothing elevated to steal.
2 Role-Based Access Control (RBAC)
RBAC assigns permissions to roles rather than configuring every user individually. NIST describes RBAC as access based on user roles, with permissions associated with those roles rather than managed directly for every individual.
Without RBAC, Alice, Bob and Charlie each need Permission 1, 2 and 3 individually assigned — three people, nine assignments to track. With RBAC, all three simply belong to a "Sales Employee" role that carries all three permissions — managing one role is far easier than managing thousands of individual grants, and it scales to an organisation of any size.
Example: a company with 10,000 employees, 500 finance employees, 80 finance managers and 20 finance admins doesn't assign thousands of individual permissions — it defines ROLE_FINANCE_EMPLOYEE, ROLE_FINANCE_ANALYST, ROLE_FINANCE_MANAGER and ROLE_FINANCE_ADMIN, each carrying the right permission set.
Business roles vs technical roles
Large IAM implementations separate the business role from the technical entitlements behind it. The business says "Alice is a Finance Analyst" — a business role like London Finance Analyst. IAM translates that into an AD group (GG-Finance-Analysts), a SAP role (Z_FINANCE_ANALYST), an Azure group, a SharePoint group, and a database role. Alice never needs to know any of those technical names.
Birthright access
Some access should apply automatically just because someone belongs to the organisation — birthright access — e.g. every employee gets Microsoft 365, the intranet, the HR portal, security awareness training, and the employee directory. Additional access then layers on top based on department, job title, country, business unit, employment type, location, or security clearance.
Role hierarchies
Roles can inherit from each other: Employee → Finance Employee → Finance Manager, where a Finance Manager gets Employee permissions plus Finance permissions plus Manager permissions. Powerful, but it needs careful design — an inheritance chain that isn't thought through is exactly how someone quietly ends up with far more access than their job requires.
Role explosion
RBAC breaks down when organisations create too many roles — Finance-London-Junior, Finance-London-Senior, Finance-Paris-Junior, Finance-Paris-Senior, Finance-Rome-Junior... a multinational could end up with tens of thousands of roles. This is role explosion, and it's why organisations increasingly combine RBAC with other models rather than trying to model every possible combination as its own role.
3 Attribute-Based Access Control (ABAC)
Instead of relying entirely on predefined roles, ABAC calculates access from attributes at evaluation time:
IF department = "Finance"
AND country = "United Kingdom"
AND employmentStatus = "Active"
THEN grant Finance UK applicationAttributes can include department, job title, location, security clearance, device state, employment type, project, or business unit. Modern enterprises typically run a mix — RBAC for the common, stable cases; ABAC and contextual/policy-based access layered on top for the situations that would otherwise require yet another one-off role.
Lab Lab 1 – Build a Simple RBAC Model
Create three users: Alice (Finance Analyst), Bob (Finance Manager), Charlie (IT Administrator). Create three roles: Finance-User, Finance-Manager, IT-Admin. Create three applications: FinanceApp, ReportingApp, AdminPortal.
🔮 Predict first
Which roles should have access to which applications? Sketch it out, then add Alice to Finance-User and confirm role membership is what actually grants her the access — not anything assigned to her directly.
Reveal a reasonable mapping
Finance-User → FinanceApp only. Finance-Manager → FinanceApp + ReportingApp. IT-Admin → AdminPortal (and arguably nothing else, per least privilege — an IT admin managing infrastructure doesn't automatically need finance data access). The point of the exercise isn't the exact mapping; it's seeing that Alice's access comes entirely from her role membership, so removing her from the role removes the access instantly, with nothing left to hunt down individually.
Lab Lab 2 – Demonstrate Least Privilege
Start with Alice provisioned as a full Administrator on a test system.
🔮 Predict first
Does Alice's actual job (say, reviewing finance reports) require administrator access? What's the minimum permission set that would let her do her job?
Reveal the exercise
Replace Alice's Administrator role with a narrow Finance-Read role and confirm she can still do her actual job. This is the entire discipline of least privilege in miniature: someone almost always has more access than their role requires, and the fix is rarely dramatic — it's usually just swapping one broad grant for a narrower one that covers exactly what's needed.
Lesson Outcome
You should now be able to explain least privilege and why privilege accumulation happens even in well-run organisations, describe how RBAC (and its business/technical role split) scales access management, recognise role explosion, and explain when ABAC complements RBAC. Lesson 2 covers what actually happens after a role decides someone needs access — provisioning, and the SCIM standard that automates it.