Identity, Access Management and Zero Trust

Introduction and context

Identity and access management (IAM) is the discipline of ensuring that the right subject obtains the right access to the right resource for the right purpose and for the right period. It is central to network and information security because most modern attacks involve misuse of legitimate identities: stolen passwords, abused privileges, compromised service accounts, or excessive permissions.

IAM is broader than logging in. It includes identity proofing, account creation, authentication, authorisation, accountability, governance, monitoring, and timely removal of access. Zero Trust extends this logic to enterprise architecture. Instead of assuming that a user or device is trustworthy because it is inside a network boundary, Zero Trust requires continuous, context-sensitive verification.

A useful security objective is to ensure that access decisions are:

• Accurate: the subject is correctly identified and authenticated.
• Appropriate: the requested operation is permitted by policy.
• Limited: privileges are restricted to business need.
• Traceable: actions can be attributed to an accountable identity.
• Revocable: access can be withdrawn quickly when circumstances change.

This chapter examines the IAM lifecycle, authentication technologies, authorisation models, directory services, federation and single sign-on (SSO), privileged access management (PAM), and the principles and implementation of Zero Trust.

Learning objectives

By the end of this chapter, students should be able to:

1. Explain identification, authentication, authorisation and accounting (the AAA functions).
2. Distinguish authentication factors and evaluate multi-factor authentication (MFA).
3. Compare discretionary, role-based, attribute-based and mandatory access control.
4. Design practical IAM controls using directories, federation, SSO and PAM.
5. Apply least privilege, separation of duties and lifecycle governance.
6. Analyse a network using Zero Trust principles.
7. Evaluate operational, ethical, legal and implementation challenges.

1. The IAM lifecycle and AAA model

1.1 Identification

Identification is the claim made by a subject about who or what it is. Examples include a username, employee number, email address, device identifier, service principal or certificate subject name. Identification alone provides no proof. A username entered into a login form is an assertion, not evidence.

An identity is a distinguishable representation of an entity in a system. The entity may be a human user, device, application, process, organisation or service account. One person may have several identities, such as a workforce identity, a privileged administrator identity and a customer identity. Good governance defines how identities are created, linked, renamed, suspended and deleted.

1.2 Authentication

Authentication verifies an identity claim using evidence called an authentication factor. The principal factor categories are:

A password and a security question are normally two knowledge factors, not two-factor authentication. MFA requires evidence from at least two independent factor categories. Independence is important: a password plus a one-time code delivered through the same compromised browser session may provide less protection than a password plus a phishing-resistant hardware authenticator.

Authentication should protect confidentiality of credentials, resist replay, limit guessing, and provide recovery processes that do not undermine the primary control. Passwords should be checked against breached-password lists, stored using a salted, slow password-hashing function, and protected from online guessing through rate limiting and adaptive controls. Password encryption that permits straightforward recovery is not equivalent to secure password hashing.

Phishing-resistant authentication, such as passkeys based on public-key cryptography, is generally stronger than SMS codes. In a public-key design, the private key remains with the authenticator and the service verifies a signature using the corresponding public key. The service does not need to store a reusable password secret.

1.3 Authorisation

Authorisation determines what an authenticated subject may do. It is a policy decision based on attributes such as identity, role, resource, requested operation, time, device health and risk.

A simple access decision can be expressed conceptually as:

Here, Permit is the decision, Authenticate(subject) indicates that the subject has met the required authentication conditions, and Policy(...) evaluates the applicable rules. The expression is a logical model rather than a universal implementation formula. Real systems may also return deny, not-applicable or indeterminate decisions, and an explicit deny should normally override a permit.

Authorisation should be denied by default, grant only necessary permissions, and separate approval from execution where high risk is involved. Authentication does not automatically imply authorisation: a valid employee account may be permitted to read a payroll system but not modify salaries.

1.4 Accounting and accountability

Accounting records relevant activity so that actions can be attributed, investigated and reviewed. Typical records include authentication events, access decisions, administrative changes, privilege elevation, data exports and policy failures.

Effective audit records contain a reliable timestamp, subject identity, source device or address, target resource, action, result and correlation identifier. Time synchronisation is essential when events from multiple systems must be reconstructed. Logs should be protected against unauthorised alteration, retained according to legal and business requirements, and monitored for meaningful events rather than merely collected.

Non-repudiation is related but distinct. A log may support accountability, but it does not by itself prove that a person could not deny an action. Stronger evidence may require cryptographic signatures, controlled key custody and trustworthy audit processes.

2. Authorisation models

2.1 Discretionary access control

In discretionary access control (DAC), the owner of an object can usually decide who may access it. Traditional file permissions and access-control lists are common examples. DAC is flexible and easy to understand, but permissions can spread through user-to-user sharing, inherited folders and uncontrolled ownership. A user who can read a sensitive file may be able to copy it into a less protected location.

2.2 Role-based access control

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles. A nurse, database administrator or purchasing officer receives the permissions associated with that job function rather than a manually constructed list.

RBAC supports role hierarchies, temporary role activation and separation-of-duties constraints. For example, one role may create a supplier and another may approve payment. RBAC is effective where organisational responsibilities are stable, but it can produce role explosion when every location, project, time condition and exception is represented as a separate role.

A sound RBAC programme requires role ownership, periodic recertification, controlled role changes and removal of unused permissions. Roles should represent business responsibilities, not merely technical groups.

2.3 Attribute-based access control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action and environment. A policy might permit a clinician to view a patient's record when the clinician is assigned to the case, is using a managed device, is within an approved location and has a legitimate treatment purpose.

ABAC provides fine-grained, context-aware decisions and can reduce role explosion. Its disadvantages include policy complexity, dependence on accurate attributes, difficult testing and limited explainability when many rules interact. Attribute sources must therefore be authoritative, timely and protected from manipulation.

2.4 Mandatory access control

Mandatory access control (MAC) uses centrally enforced classifications and clearances. Subjects and objects receive labels, and a subject's clearance must satisfy the policy for the object. Users cannot normally change the rule merely because they own the file. MAC is suitable for environments such as defence or regulated information processing where information-flow rules must be centrally imposed.

A simplified confidentiality model is the Bell–LaPadula principle: a subject should not read information above its clearance and should not write information to a lower classification. This is often summarised as “no read up, no write down.” The model focuses on confidentiality, not on all integrity or availability concerns, and real systems require additional controls.

2.5 Comparing models

Organisations often combine models. For example, RBAC may establish baseline permissions, while ABAC checks device posture, location and risk before permitting a particular transaction.

3. Identity infrastructure

3.1 Directory services

A directory service stores and retrieves identity-related objects such as users, groups, devices, certificates and organisational units. Lightweight Directory Access Protocol (LDAP) is a common protocol for querying and managing directory information. Enterprise directory platforms often provide authentication integration, group management, policy distribution and replication.

Directory design affects security. Administrative boundaries should reflect trust boundaries; highly privileged accounts should not be used for routine email or web browsing; service accounts should have named owners and documented purposes; and inactive identities should be disabled promptly. Directory synchronisation must be monitored because an error in a source system can create or remove access across many applications.

3.2 Federation and SSO

Federation allows one organisation or identity provider (IdP) to make authentication assertions that another service provider (SP) trusts. The IdP authenticates the user, while the SP relies on a signed assertion or token containing selected claims. Federation reduces password duplication and enables central policy enforcement, but trust relationships must be governed carefully.

SSO lets a user authenticate once and access multiple approved services. Its benefits include reduced password reuse, simpler account termination and improved usability. Its concentration of risk is significant: compromise of the central identity provider can affect many services. Strong MFA, resilient recovery, carefully scoped tokens, session controls and monitoring are therefore essential.

Common federation technologies include Security Assertion Markup Language (SAML), commonly used for browser-based enterprise federation, and OpenID Connect (OIDC), an identity layer built on OAuth 2.0. OAuth primarily concerns delegated authorisation; it is not, by itself, a complete user-authentication protocol. Confusing OAuth access delegation with authentication can lead to insecure designs.

3.3 Provisioning and deprovisioning

Identity governance connects human-resources, student, contractor and application systems. A joiner–mover–leaver process should:

1. Create an identity from an authoritative source.
2. Assign baseline access according to job, programme or contract.
3. Require approval for exceptional access.
4. Recalculate access when duties change.
5. Disable accounts and revoke sessions when relationships end.
6. Preserve necessary records without retaining unnecessary access.

Deprovisioning must include API tokens, certificates, VPN accounts, mobile sessions, delegated permissions and cloud accounts, not only the primary directory password. Periodic access reviews should test whether access remains necessary, not simply ask managers to approve a preselected list without scrutiny.

4. MFA and privileged access management

4.1 Selecting MFA

MFA should be proportionate to risk. High-value administrators, remote access, financial transactions and sensitive data require stronger controls than low-risk public information. Important design considerations include phishing resistance, device loss, accessibility, recovery, enrolment assurance and protection against social engineering.

SMS-based codes can be better than passwords alone but are exposed to interception, SIM-swap fraud and social engineering. Push approvals can suffer from notification fatigue. Number matching, transaction context and phishing-resistant authenticators reduce these weaknesses. Biometrics are convenient but are not secrets that can simply be replaced after compromise; they should generally unlock a protected device or cryptographic key rather than serve as the sole remote credential.

4.2 Privileged access management

Privileged accounts can change security settings, access sensitive records, create identities or disable controls. PAM reduces their exposure through:

• Separate administrator and ordinary-user accounts.
• Just-in-time or time-limited privilege elevation.
• Approval workflows for high-risk operations.
• Credential vaulting and automated rotation.
• Session recording or command logging where lawful and proportionate.
• Restrictions on direct interactive use of service accounts.
• Emergency access (“break-glass”) accounts with strong protection and mandatory review.

PAM is not simply a password vault. It is a governance and monitoring capability that limits standing privilege and improves attribution. Break-glass access must be tested, but tests should be controlled so they do not create an unmonitored route around normal controls.

4.3 Separation of duties and least privilege

Least privilege grants only the access necessary for an assigned task. Separation of duties ensures that one person cannot complete a sensitive process without an independent control. These principles reduce fraud and limit damage after account compromise, but excessive restrictions can encourage workarounds. Access design should therefore consider real workflows, emergency procedures and usability.

5. Zero Trust architecture

5.1 Core principles

Zero Trust is a security strategy, not a single product. Its central proposition is “never trust automatically; verify explicitly.” Trust is not granted solely because a user is on an internal network, connected through a VPN or using a corporate device.

A practical Zero Trust architecture applies the following principles:

• Verify identity, device, application, resource and transaction context.
• Use least-privilege, resource-specific access.
• Assume breach and limit lateral movement.
• Make access decisions dynamically where risk changes.
• Collect telemetry and continuously improve policy.
• Protect data through classification, encryption, segmentation and monitoring.

A conceptual access transaction is:

The arrow represents a policy decision point. The decision may be permit, deny, or require additional verification. A policy enforcement point applies the decision, while identity, device-management, threat-intelligence and resource systems provide evidence.

5.2 Architecture components

A Zero Trust design commonly includes:

• Policy engine: evaluates rules and risk signals.
• Policy administrator: establishes or changes the communication path and session conditions.
• Policy enforcement point: permits, blocks or limits traffic and application actions.
• Identity provider: authenticates users and issues claims.
• Device-management platform: reports configuration and health.
• Security analytics: identifies suspicious behaviour.
• Data and application controls: enforce access near the protected resource.

Microsegmentation can reduce lateral movement by separating workloads, users and services according to business need. It should be based on observed communication flows and tested incrementally; arbitrary segmentation can interrupt legitimate dependencies and drive users toward insecure exceptions.

5.3 Zero Trust is not a perimeter replacement alone

A VPN may authenticate a user and create a broad network path, whereas Zero Trust seeks application- or resource-specific access. However, a VPN can coexist with Zero Trust during transition. Likewise, Zero Trust does not mean continuous intrusive surveillance, universal denial, or elimination of all network boundaries. It is a risk-management approach requiring proportionate controls, reliable evidence and explicit governance.

6. Applied case: illustrative university research environment

Background

A fictional university operates a research platform containing controlled health data. Researchers use campus networks, home networks and partner institutions. The platform has a central directory, several legacy applications and shared laboratory accounts.

Problem

A former researcher retained access through an application-specific account. A current researcher used a shared laboratory password, and an attacker later accessed the platform from an unmanaged device. Logs could not reliably distinguish individual actions. The university had MFA for remote VPN access but not for the research applications themselves.

Analysis

The environment had weaknesses across the IAM lifecycle. Identification was ambiguous because of shared accounts. Authentication was weak because the shared password was reusable. Authorisation was broader than research duties required. Accounting was inadequate because actions could not be attributed. The VPN created a trusted network path but did not establish that the endpoint was secure or that each application action was legitimate.

Approach and solution

The university adopted the following phased design:

1. Each researcher received an individual federated identity linked to the authoritative staff or student record.
2. Shared accounts were removed except for tightly controlled technical functions.
3. Phishing-resistant MFA was required for researchers and mandatory for administrators.
4. RBAC provided baseline roles, while ABAC checked project assignment, device management and data classification.
5. Sensitive datasets required approval by both a project owner and a data custodian.
6. Privileged administration used separate accounts, time-limited elevation and session logging.
7. Application-specific accounts and tokens were inventoried, assigned owners and rotated.
8. Application-level enforcement replaced broad VPN trust; segmentation restricted laboratory workloads.
9. Logs were centralised, time-synchronised and reviewed for unusual downloads, impossible travel and privilege changes.
10. Quarterly access reviews and immediate leaver deprovisioning were implemented.

Outcome

The university improved attribution, reduced standing privilege and limited access from unmanaged devices. Researchers experienced additional enrolment and approval steps, so the security team introduced clear exception processes and usability testing. The outcome demonstrates that Zero Trust is a socio-technical programme: technology, policy, identity data, user behaviour and governance must work together.

Learning points

• Removing shared identities is often more valuable than adding another perimeter device.
• Federation can centralise authentication, but each application still needs correct authorisation.
• Device and project context can make access more precise than job title alone.
• Logging must be designed for investigation and accountability.
• Exceptions should be documented, time-limited and reviewed rather than becoming permanent bypasses.

7. Governance, ethics and regulatory considerations

IAM processes personal data. Biometric templates, location signals, behavioural analytics and access logs can reveal sensitive information. Organisations should apply purpose limitation, data minimisation, retention limits, transparency and access controls to IAM data. Monitoring should be proportionate and should not treat statistical anomaly as proof of misconduct.

Regulatory requirements vary by jurisdiction and sector, but common expectations include controlled access, separation of duties, audit trails, periodic reviews, incident response and prompt revocation. Legal compliance is a baseline, not a substitute for risk analysis. Cross-border federation also raises questions about data transfer, jurisdiction, identity assurance and contractual responsibility.

Accessibility and inclusion are security concerns. A design that requires a single type of phone, excludes users with disabilities or makes recovery impossible can create unsafe workarounds. Alternative authenticators, accessible enrolment and supervised recovery should be planned from the beginning.

Artificial intelligence can support anomaly detection, entitlement analysis and policy recommendation. It should not be trusted as an unreviewed authority for high-impact access decisions. Models may produce false positives, encode bias, expose sensitive telemetry or be manipulated by attackers. Human oversight, explainability appropriate to the risk, testing and appeal procedures remain necessary.

8. Implementation and evaluation

A practical IAM programme can proceed as follows:

1. Inventory identities, accounts, applications, data and privileged paths.
2. Identify authoritative sources and eliminate orphaned accounts.
3. Classify resources and map business processes.
4. Establish baseline RBAC and introduce ABAC where context is necessary.
5. Deploy strong MFA, beginning with privileged and externally exposed access.
6. Implement joiner–mover–leaver automation.
7. Reduce standing privilege through PAM.
8. Integrate federation and SSO with carefully scoped trust.
9. Apply resource-level Zero Trust controls and segmentation.
10. Measure, review and improve.

Useful measures include the percentage of users enrolled in strong MFA, time to disable leaver accounts, number and age of orphaned accounts, privileged accounts with standing access, completion quality of access reviews, unauthorised access attempts, policy exceptions and mean time to revoke compromised credentials. Metrics should indicate risk reduction, not merely deployment activity. For example, “100% of applications integrated with SSO” does not prove that excessive application permissions have been removed.

Challenges and limitations

IAM programmes commonly encounter legacy systems, incomplete identity data, inconsistent role definitions, complex mergers, service-account sprawl and resistance to additional authentication steps. Centralisation can create a single point of failure, while overly complex policies can produce unpredictable results. MFA reduces account-takeover risk but cannot prevent every authorised insider action or compromised endpoint. Zero Trust depends on trustworthy telemetry; inaccurate device health or identity data can produce either dangerous permits or disruptive denials.

Organisations should use staged implementation, strong change control, testing in representative workflows, resilient identity-provider architecture and well-governed emergency access. Security teams should document assumptions and regularly test whether controls operate as designed under account compromise, directory failure, lost authenticators and supplier outages.

Chapter Summary

IAM provides the lifecycle controls through which organisations identify subjects, authenticate claims, authorise actions and record activity. Identification is not proof, authentication is not authorisation, and accounting is necessary for accountability and investigation. MFA is strongest when it uses independent, phishing-resistant factors and has secure recovery.

DAC, RBAC, ABAC and MAC solve different policy problems. RBAC aligns access with job responsibilities, ABAC adds contextual precision, DAC offers owner flexibility, and MAC imposes centrally controlled information-flow rules. Directory services, federation and SSO simplify identity management but concentrate risk in identity providers and trust relationships. PAM limits the impact of administrative accounts through separation, time-limited elevation, vaulting and monitoring.

Zero Trust treats every access request as a policy decision requiring explicit evidence about the subject, device, application, resource and context. It applies least privilege, assumes breach, limits lateral movement and uses continuous telemetry. Effective implementation is socio-technical: governance, user experience, privacy, reliable identity data and resilient technology are all necessary.

Key Terms

Accounting: Recording identity and access activity for accountability and investigation.

ABAC: Access control based on subject, resource, action and environmental attributes.

Authentication: Verification of an identity claim.

Authorisation: Determination of permitted actions after authentication.

DAC: Access control in which an object owner can generally grant permissions.

Directory service: A system that stores and provides identity and organisational information.

Federation: Trust arrangement in which one identity provider supplies assertions to another service.

Identity: A representation of a distinguishable subject in a system.

IdP: Identity provider that authenticates users and issues claims or tokens.

Least privilege: Granting only the access necessary for a task.

MAC: Centrally enforced access control using classifications and clearances.

MFA: Authentication using evidence from at least two independent factor categories.

PAM: Controls for governing, restricting and monitoring privileged access.

RBAC: Access control based on organisational roles and their permissions.

Separation of duties: Dividing sensitive responsibilities among independent people or roles.

SSO: A capability allowing one authentication event to support access to multiple services.

Zero Trust: A strategy that verifies access explicitly rather than trusting network location.

Policy enforcement point: A component that applies an access decision to a request.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication and authorisation.
2. Why are a password and a security question usually not MFA?
3. State two advantages and one limitation of RBAC.
4. What is the purpose of privileged access management?
5. Why does Zero Trust reject implicit trust based solely on network location?

Long Answer Questions

1. Compare DAC, RBAC, ABAC and MAC, including an appropriate use case for each.
2. Explain how directory services, federation and SSO can improve security while also concentrating risk.
3. Design a joiner–mover–leaver process for a medium-sized organisation.
4. Discuss the technical and governance controls required for a secure PAM programme.
5. Explain how a university could transition from VPN-centred security to application-level Zero Trust.

Analytical / Application Questions

1. An employee moves from finance to research but retains access to payroll and gains access to a sensitive research dataset. Analyse the IAM failures and propose corrective controls.
2. A company uses RBAC but has more than 400 roles because each role includes location, project and time conditions. Explain why this occurred and recommend a combined RBAC–ABAC design.
3. An administrator authenticates with MFA from a managed laptop, but begins downloading unusually large volumes of data. Apply Zero Trust principles to determine what additional controls or decisions should occur.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorisation?

A. Authentication determines what a user may do; authorisation identifies the user.

B. Authentication verifies an identity claim; authorisation determines permitted actions.

C. Authentication records events; authorisation encrypts credentials.

D. Authentication assigns roles; authorisation creates directory accounts.

Correct Answer: B. Authentication verifies an identity claim; authorisation determines permitted actions.

Question 2

Which combination most clearly represents MFA?

A. Password and security question

B. PIN and password

C. Password and hardware security key

D. Two different passwords

Correct Answer: C. Password and hardware security key

Question 3

Which access-control model evaluates subject, resource and environmental attributes?

A. DAC

B. RBAC

C. MAC

D. ABAC

Correct Answer: D. ABAC

Question 4

What is a major security benefit of just-in-time privileged access?

A. It eliminates the need for authentication.

B. It reduces standing administrative privilege.

C. It allows all users to become administrators permanently.

D. It replaces audit logging.

Correct Answer: B. It reduces standing administrative privilege.

Question 5

In federation, what is the usual role of an identity provider?

A. It physically segments the network.

B. It authenticates the user and provides an assertion or token.

C. It stores every application’s business data.

D. It disables authorisation at the service provider.

Correct Answer: B. It authenticates the user and provides an assertion or token.

Question 6

Which statement about OAuth 2.0 is most accurate?

A. It is primarily a delegated-authorisation framework.

B. It is a password-hashing algorithm.

C. It is a mandatory-access classification model.

D. It is a directory replication protocol.

Correct Answer: A. It is primarily a delegated-authorisation framework.

Question 7

Which principle is most characteristic of Zero Trust?

A. Trust all internal traffic by default.

B. Grant broad network access after VPN authentication.

C. Verify access explicitly using identity, device and context.

D. Remove all network segmentation.

Correct Answer: C. Verify access explicitly using identity, device and context.

Question 8

A former employee can still access an application through an old token even though the directory account is disabled. Which control failure is most directly indicated?

A. Incomplete deprovisioning

B. Role hierarchy design

C. Biometric matching

D. Network time synchronisation

Correct Answer: A. Incomplete deprovisioning

Question 9

What does separation of duties primarily reduce?

A. The need for identity records

B. The possibility that one person can complete a sensitive process alone

C. The availability of directory services

D. The value of audit logs

Correct Answer: B. The possibility that one person can complete a sensitive process alone

Question 10

Which statement about biometrics is correct?

A. Biometric characteristics can always be replaced like passwords.

B. Biometrics are normally classified as a knowledge factor.

C. Biometrics are often used to unlock a device or cryptographic authenticator.

D. Biometrics eliminate the need for recovery procedures.

Correct Answer: C. Biometrics are often used to unlock a device or cryptographic authenticator.