4. Identity Security and Zero Trust

Introduction and Context

Identity has become the principal security boundary of modern digital enterprises. Applications are distributed across data centres, public clouds, software-as-a-service platforms, mobile devices, operational technology environments, and partner networks. Users may work from several locations and use unmanaged or partially managed devices, while automated services communicate continuously through application programming interfaces (APIs). In such an environment, the traditional assumption that users and systems inside a network can be trusted is unsafe.

Identity security addresses the protection and governance of digital identities throughout their life cycle. It includes establishing who or what is requesting access, deciding what that identity should be permitted to do, enforcing the decision, monitoring activity, and withdrawing access when circumstances change. Zero Trust extends this logic into an architectural and governance philosophy: no request is trusted merely because of network location or previous authentication. Access is granted dynamically, with the minimum necessary privilege, after evaluating relevant evidence.

This chapter examines authentication, federation, OAuth and OpenID Connect (OIDC), Security Assertion Markup Language (SAML), multifactor authentication (MFA), privileged access management (PAM), role-based and attribute-based access control, machine identities, and implementation strategies for Zero Trust. The emphasis is not on purchasing a product but on designing an integrated identity-control system that is secure, usable, auditable, and aligned with organizational risk.

Learning Objectives

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

1. Distinguish identification, authentication, authorization, accounting, and federation.

2. Design an identity and access management (IAM) architecture for human and machine identities.

3. Compare SAML, OAuth 2.0, and OIDC according to their purposes and security properties.

4. Evaluate MFA, PAM, RBAC, ABAC, and lifecycle governance decisions.

5. Explain the principles and logical architecture of Zero Trust.

6. Develop a phased Zero Trust implementation roadmap with meaningful measures of progress.

7. Identify technical, organizational, ethical, and regulatory risks in identity programs.

From Network Perimeters to Identity-Centred Security

A conventional perimeter model treats a corporate network as relatively trustworthy and external networks as hostile. Firewalls, virtual private networks, and network segmentation remain useful, but they cannot by themselves establish whether a request is legitimate. Credentials may be stolen, internal systems may be compromised, and cloud resources may not sit behind a single enterprise perimeter. A valid user account can also be abused by malware or an insider.

Identity security therefore separates several activities that are often confused. Identification is the assertion of an identity, such as entering a username. Authentication verifies that assertion. Authorization determines what the authenticated subject may do. Accounting, often expressed through logging and audit trails, records relevant activity. A secure design treats these as related but distinct controls. Successful authentication does not imply unlimited authorization.

An identity may represent an employee, contractor, customer, administrator, workload, device, service account, API client, or robotic process. Each identity requires an owner, a defined purpose, appropriate credentials, lifecycle controls, and evidence of use. The absence of ownership is particularly dangerous for shared and machine accounts because responsibility for misuse becomes difficult to establish.

Authentication and Federation

Authentication factors are commonly grouped into knowledge factors, possession factors, and inherence factors. Passwords and PINs are knowledge factors; hardware security keys and authenticator applications are possession factors; fingerprints and facial characteristics are inherence factors. MFA requires two or more independent factors. Using a password and a second password is not genuine MFA because both belong to the same factor category.

MFA reduces the consequences of password compromise, but its strength depends on implementation. One-time codes delivered through some channels can be exposed to phishing or telecommunications attacks. Phishing-resistant methods, such as cryptographic security keys and platform authenticators, bind authentication to the legitimate service and are generally stronger for high-risk access. Recovery procedures must receive the same attention as primary authentication; an attacker who can bypass MFA through weak account recovery can defeat the entire control.

Federation allows an identity provider (IdP) to authenticate a user for a relying party or service provider. The user may therefore access several services without each service independently storing a password. Federation can improve usability, centralize policy, and support rapid employee offboarding. It also creates concentration risk: compromise or unavailability of the IdP may affect many applications. Strong administrative protection, resilient architecture, careful trust configuration, and independent emergency access are consequently essential.

SAML is an XML-based framework widely used for exchanging authentication and authorization assertions, especially in enterprise web single sign-on. An IdP issues a signed assertion that a service provider validates. Administrators must protect signing keys, validate audience and time conditions, prevent assertion replay, and avoid accepting improperly configured assertions.

OAuth 2.0 is an authorization framework, not an authentication protocol. It enables a resource owner to delegate limited access to a client through access tokens. OIDC adds an identity layer to OAuth 2.0 by introducing an ID token and standardized claims for authenticating the user. A practical distinction is therefore: SAML and OIDC commonly support federated sign-in, while OAuth primarily governs delegated API access. Misusing an access token as proof of identity, failing to validate an ID token, or placing tokens in insecure browser storage are common design errors.

Authorization Code with Proof Key for Code Exchange (PKCE) is an important modern pattern for public clients. PKCE helps prevent an intercepted authorization code from being exchanged by an attacker. Secure implementations also validate issuer, audience, nonce, state, redirect URI, token lifetime, and requested scopes. Tokens should be narrowly scoped, short-lived where feasible, protected in transit and at rest, and revoked or rotated when risk warrants.

Access Decisions: RBAC, ABAC, and Policy Engines

Role-based access control (RBAC) grants permissions through roles such as payroll analyst, database administrator, or help-desk agent. RBAC is understandable and administratively efficient when job responsibilities are stable. However, organizations can accumulate excessive roles, conflicting permissions, and “role explosion” when every departmental variation becomes a separate role.

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might permit a clinician to view records only when the clinician is assigned to the patient, the device is managed, the request originates from an approved context, and the purpose is treatment. ABAC supports fine-grained and contextual decisions but requires accurate attributes, policy expertise, explainability, and reliable policy-enforcement points.

Many mature programs combine the two approaches. RBAC provides a stable baseline, while attributes constrain access at decision time. Policy decision points evaluate rules; policy enforcement points intercept requests; policy information points supply trusted attributes; and policy administration points manage policy. Separation of these functions supports consistency across cloud, application, and infrastructure environments.

Least privilege means granting only the access necessary for an approved purpose and duration. It is not merely a technical setting; it is a governance discipline requiring access reviews, separation of duties, expiry dates, and attention to indirect privileges. A user who cannot directly alter payroll but can change a script that performs payroll processing may still possess effective privilege.

Privileged Access and Identity Lifecycle Governance

Privileged accounts can change configurations, create identities, disable controls, or access sensitive information. PAM reduces their exposure through vaulting credentials, just-in-time elevation, approval workflows, session recording, command restriction, and rapid revocation. Administrative accounts should be separate from ordinary accounts, protected with strong MFA, and used only for administrative activity.

A sound PAM program begins with discovery. Organizations must identify domain administrators, cloud administrators, database owners, service principals, emergency accounts, embedded credentials, and privileged API keys. Password rotation alone is insufficient if privileged access is permanent, unmonitored, or granted to broad groups. Just-in-time access is preferable where operationally feasible, but emergency access must be designed, tested, and reviewed rather than eliminated.

Identity governance covers joiner, mover, and leaver processes. A reliable source of employment or contractual status should trigger account creation, modification, and termination. Access should be approved by an accountable owner, reconciled against actual use, and periodically recertified. Dormant accounts, orphaned accounts, excessive entitlements, and unowned service accounts are indicators of weak governance.

Access reviews should be risk-based. A review of a low-risk collaboration group need not resemble a review of production database administrators. Reviewers need useful context: the entitlement, business purpose, last use, data sensitivity, and consequences of removal. Rubber-stamp approvals provide the appearance rather than the substance of governance.

Machine Identities and Non-Human Access

Machine identities include workloads, containers, virtual machines, devices, service accounts, API clients, certificates, and cryptographic keys. In many environments they outnumber human identities and often possess broad, persistent privileges. Their security requires an accountable owner, documented purpose, constrained permissions, secure provisioning, rotation, monitoring, and retirement.

Long-lived static secrets in source code, configuration files, or shared repositories are especially hazardous. Better approaches include managed identities, workload identity federation, short-lived certificates or tokens, hardware-backed key storage, and automated secret rotation. Mutual TLS can authenticate services to one another, while signed tokens can convey narrowly defined claims. Nevertheless, automation must not be mistaken for security: an automated process with excessive privilege can cause damage at machine speed.

A useful design question is not simply “Is this service trusted?” but “What specific action is this workload requesting, against which resource, under what conditions, and with what evidence?” Service-to-service authorization should be explicit, observable, and independently revocable.

Zero Trust as an Operating Model

Zero Trust is commonly summarized as “never trust, always verify,” but the phrase is meaningful only when translated into controls. A Zero Trust architecture assumes that compromise is possible, verifies explicitly using multiple signals, applies least privilege, and limits the blast radius of successful attacks. Network location is one signal, not a sufficient basis for trust.

The main logical elements are a policy engine that makes or recommends an access decision, a policy administrator that communicates the decision, and policy enforcement points that permit, restrict, or terminate sessions. Decisions may incorporate identity assurance, device posture, application sensitivity, resource classification, request context, threat intelligence, and behavioural risk. Continuous monitoring can trigger reauthentication, step-up MFA, session termination, or privilege reduction.

Zero Trust is not equivalent to MFA, microsegmentation, or a particular commercial platform. MFA may strengthen identity assurance, while segmentation limits movement; neither alone creates a complete Zero Trust program. The approach must include data, applications, devices, networks, workloads, and visibility. It also requires cooperation among security, infrastructure, application, human resources, legal, privacy, and business teams.

A practical implementation roadmap begins with governance and scope. The organization identifies critical business services, crown-jewel data, users, workloads, dependencies, and existing controls. It then establishes a target architecture and prioritizes high-risk journeys rather than attempting an uncontrolled enterprise-wide transformation. Typical phases include:

• establish identity inventory, ownership, MFA, lifecycle controls, and privileged-account protection;
• classify applications and data, map transaction flows, and remove unnecessary access;
• modernize federation, device signals, workload identity, and policy enforcement;
• introduce contextual access, segmentation, continuous monitoring, and automated response; and
• measure outcomes, test resilience, and refine policies through operational feedback.

Useful measures include the percentage of privileged accounts protected by phishing-resistant MFA, time to disable leavers, percentage of applications federated, number of standing privileged entitlements, age of unrotated secrets, high-risk access-review exceptions, and mean time to revoke compromised sessions. Metrics should measure risk reduction, not merely the number of deployed tools.

An Illustrative Case: Northbridge Health Services

Background

Northbridge Health Services is a fictional regional healthcare organization operating hospitals, outpatient clinics, a research environment, and a patient portal. Its workforce uses a mixture of cloud and legacy applications. Clinicians need access from wards and remote locations, while researchers require access to selected datasets.

Situation and Analysis

An internal review found shared administrator accounts, inconsistent MFA, service credentials embedded in scripts, and delayed removal of departing staff. A flat network allowed a compromised workstation to reach several clinical systems. The organization initially proposed purchasing a single Zero Trust platform, but analysis showed that technology alone would not resolve unclear data ownership, weak joiner-leaver processes, or excessive application permissions.

Strategy and Solution

Northbridge first established an identity authority linked to human resources and separated ordinary and privileged accounts. It introduced phishing-resistant MFA for administrators and remote access, then extended appropriate MFA to clinical users with carefully designed recovery procedures. SAML and OIDC federation were adopted for modern applications, while legacy systems were placed behind controlled access gateways.

The organization classified clinical, research, and administrative data; assigned application owners; and created baseline RBAC roles. ABAC conditions were added for sensitive records, considering clinical assignment, device posture, purpose, and location. PAM provided vaulted credentials, just-in-time elevation, approvals, and session logging. Static service passwords were replaced progressively with managed workload identities and short-lived credentials.

Network and application flows were mapped before segmentation. High-value clinical systems received enforcement points that evaluated identity, device health, application sensitivity, and risk signals. Security operations integrated identity logs with endpoint and network telemetry so that a suspicious session could be challenged or terminated.

Outcome

The program reduced standing administrative access, improved visibility of machine accounts, and shortened leaver deprovisioning. It also exposed usability problems: some clinical workflows depended on rapid access during emergencies, and poorly designed prompts could encourage unsafe workarounds. The organization therefore created emergency-access procedures, tested downtime operations, involved clinicians in policy design, and measured both security and service-disruption indicators.

Learning Points

The case illustrates that Zero Trust is an iterative operating model rather than a single deployment. Identity inventory, ownership, strong authentication, lifecycle discipline, application modernization, and monitoring were mutually reinforcing. The most important architectural decisions were driven by business services and risk, not by network diagrams alone.

Risks, Limitations, and Professional Judgement

Identity systems create valuable central control but also become high-impact targets. An IdP outage can interrupt many services; a compromised administrator can affect the entire enterprise; inaccurate attributes can produce discriminatory or unsafe decisions. Centralization should therefore be balanced with resilience, tested recovery, protected break-glass accounts, and independent monitoring.

Overly strict policies can harm availability and encourage shadow IT, password sharing, or unsafe bypasses. Excessive prompts may produce MFA fatigue, while poorly designed biometrics can create privacy and accessibility concerns. Security teams should assess usability, provide accessible alternatives, and distinguish malicious resistance from legitimate operational requirements.

Automation introduces additional risk. A policy engine may make rapid decisions based on incomplete or stale information. Machine-learning risk scores can be opaque, reproduce biased data, or generate false positives. High-impact decisions should have explainability, appeal or review mechanisms, conservative failure modes, and human oversight where appropriate.

Governance must address privacy, employment obligations, data minimization, retention, cross-border transfers, and lawful monitoring. Logs should be sufficient for investigation without collecting unnecessary personal information. Access decisions and monitoring practices should be documented, communicated, and reviewed by appropriate legal, privacy, risk, and ethics functions.

Emerging Directions and Best Practices

Current development is moving toward passwordless authentication, phishing-resistant credentials, decentralized or portable identity concepts, continuous authorization, confidential computing, and stronger workload identity for cloud-native systems. Artificial intelligence is increasingly used to identify anomalous sign-ins, discover entitlement patterns, and prioritize access reviews. Such tools should support analysts rather than silently determine consequential access without validation.

Effective practice can be summarized as follows:

1. Treat every identity as an owned, governed asset.

2. Prefer phishing-resistant MFA for privileged and high-risk access.

3. Separate authentication from authorization and validate tokens rigorously.

4. Apply least privilege, time limitation, separation of duties, and explicit purpose.

5. Protect machine identities with short-lived, rotated, and attributable credentials.

6. Design lifecycle processes with authoritative sources and measurable service levels.

7. Combine RBAC’s manageability with ABAC’s contextual precision where justified.

8. Build resilience for identity-provider failure and emergency access.

9. Integrate identity, endpoint, application, and security-monitoring data.

10. Implement Zero Trust incrementally around critical business services and test outcomes continuously.

Chapter Summary

Identity security establishes who may access an organization’s resources, under which conditions, and with what accountability. Authentication verifies identity, while authorization determines permissible action; federation enables trusted identity exchange across services. SAML supports enterprise assertions, OAuth 2.0 supports delegated authorization, and OIDC adds authentication to OAuth. MFA, especially phishing-resistant MFA, strengthens assurance but must include secure recovery.

RBAC provides manageable role structures, ABAC enables contextual decisions, and policy architectures combine decision, information, administration, and enforcement functions. PAM protects high-impact privileges, while identity governance manages joiner, mover, and leaver events. Machine identities require ownership, narrowly scoped permissions, short-lived credentials, rotation, and monitoring.

Zero Trust assumes that compromise is possible and requires explicit verification, least privilege, continuous evaluation, and reduced blast radius. Successful implementation is phased: establish identity and privilege foundations, classify resources, modernize federation and workload access, introduce contextual controls, and measure risk reduction. Resilience, privacy, usability, explainability, and organizational ownership are as important as technology.

Key Terms

Identity and Access Management (IAM): The governance and technical discipline for managing identities and their access to resources.

Authentication: Verification that an asserted identity is genuine.

Authorization: Determination of the actions an authenticated identity may perform.

Federation: Agreement and technical mechanism enabling one identity domain to authenticate users for another service.

Identity Provider (IdP): System that authenticates identities and issues assertions or tokens.

SAML: XML-based standard for exchanging signed authentication and authorization assertions.

OAuth 2.0: Framework for delegated authorization and controlled access to protected resources.

OpenID Connect: Authentication and identity layer built on OAuth 2.0.

Multifactor Authentication: Authentication using two or more independent factor categories.

Phishing-resistant authentication: Authentication designed to prevent credentials being replayed at an imposter service.

RBAC: Access control based on organizational roles.

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

Privileged Access Management: Controls for discovering, restricting, monitoring, and governing high-impact access.

Machine identity: Identity representing a workload, device, service, application, or automated process.

Least privilege: Granting only the access necessary for an approved purpose and period.

Policy Enforcement Point: Component that permits, denies, restricts, or terminates a requested action.

Zero Trust: Security approach requiring explicit verification and least privilege rather than implicit network-based trust.

Break-glass account: Emergency account used under controlled conditions when normal access mechanisms fail.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.

2. Why is OAuth 2.0 not, by itself, an authentication protocol?

3. State two advantages and one risk of identity federation.

4. What is the purpose of just-in-time privileged access?

5. Define a machine identity and identify one control required to protect it.

Long Answer Questions

1. Compare SAML, OAuth 2.0, and OIDC in terms of purpose, tokens or assertions, and common use cases.

2. Explain how RBAC and ABAC can be combined in a large enterprise.

3. Describe a complete identity lifecycle governance process for joiners, movers, and leavers.

4. Explain the logical components and operating principles of a Zero Trust architecture.

5. Develop a phased Zero Trust roadmap for an organization with legacy applications and cloud services.

Analytical / Application Questions

1. A contractor’s account has MFA but retains permanent administrator privileges after a project ends. Analyze the control failures and propose corrective measures.

2. An API client uses a long-lived secret stored in a source-code repository. Design a safer machine-identity pattern and explain its operational trade-offs.

3. A hospital wants to require contextual access controls but fears that excessive prompts will delay emergency treatment. Propose a balanced policy and the metrics that should be monitored.

22. Multiple Choice Questions with Answers

Question 1

Which statement most accurately distinguishes OAuth 2.0 from OIDC?

A. OAuth 2.0 authenticates users, while OIDC encrypts databases.

B. OAuth 2.0 governs delegated authorization, while OIDC adds an identity layer for authentication.

C. OAuth 2.0 is an XML assertion protocol, while OIDC is a network firewall standard.

D. OAuth 2.0 is only for administrators, while OIDC is only for devices.

Correct Answer: B. OAuth 2.0 governs delegated authorization, while OIDC adds an identity layer for authentication.

Question 2

Which control best reduces the risk of an intercepted authorization code being reused by a public client?

A. Using a longer username

B. Disabling token expiration

C. Using PKCE with the authorization code flow

D. Storing the code in a shared file

Correct Answer: C. Using PKCE with the authorization code flow

Question 3

A policy permits access only when the user is assigned to a patient, the device is managed, and the request has a treatment purpose. This is primarily an example of:

A. ABAC

B. Static RBAC

C. Password federation

D. Network address translation

Correct Answer: A. ABAC

Question 4

Which practice is most characteristic of privileged access management?

A. Giving all employees the same administrator account

B. Eliminating all audit logs to protect privacy

C. Providing permanent privileges without approval

D. Using vaulting, just-in-time elevation, and session monitoring

Correct Answer: D. Using vaulting, just-in-time elevation, and session monitoring

Question 5

Under a Zero Trust approach, network location should be treated as:

A. The sole basis for authorization

B. A sufficient substitute for MFA

C. One contextual signal among several

D. Proof that a user is trustworthy

Correct Answer: C. One contextual signal among several

Question 6

Which design is strongest for a cloud workload requiring access to a storage service?

A. A shared password embedded in application source code

B. A permanent administrator API key

C. A managed workload identity with narrowly scoped, short-lived credentials

D. A credential sent through email whenever the workload runs

Correct Answer: C. A managed workload identity with narrowly scoped, short-lived credentials

Question 7

Why can a centralized identity provider create concentration risk?

A. It prevents all forms of federation

B. Its compromise or outage may affect many dependent services

C. It makes authorization impossible

D. It eliminates the need for access reviews

Correct Answer: B. Its compromise or outage may affect many dependent services

Question 8

Which metric most directly measures improvement in leaver access governance?

A. Number of firewall rules

B. Average length of employee passwords

C. Time taken to disable access after employment termination

D. Number of software vendors

Correct Answer: C. Time taken to disable access after employment termination

Question 9

A company creates a separate role for every minor departmental variation and soon has thousands of roles. This illustrates:

A. Role explosion

B. Token replay

C. Credential stuffing

D. Certificate pinning

Correct Answer: A. Role explosion

Question 10

Which statement best reflects a mature Zero Trust implementation strategy?

A. Deploy one product across the enterprise before identifying critical services

B. Replace all authorization decisions with network segmentation

C. Begin with high-risk business services and incrementally improve identity, privilege, enforcement, and monitoring

D. Trust internal users after one successful login

Correct Answer: C. Begin with high-risk business services and incrementally improve identity, privilege, enforcement, and monitoring