7. Identity, Access and Zero-Trust Security

Introduction and Context

Identity is the organizing principle of modern information security. Networks, applications, cloud services, data platforms, industrial systems, and increasingly autonomous software agents all require decisions about who or what is requesting access, under which conditions, and to which resources. Traditional perimeter security assumed that users and devices inside a trusted network could receive comparatively broad access. That assumption is inadequate in environments characterized by cloud computing, remote work, mobile devices, software-as-a-service, supply-chain dependencies, and persistent credential attacks.

Identity and access management (IAM) therefore extends beyond account administration. It is a governance and engineering discipline concerned with the complete identity lifecycle, authentication, authorization, accountability, and the continual adjustment of access according to risk. Zero-trust security builds on this discipline by rejecting implicit trust based on network location or previous authentication. Every access request is evaluated in context, and access is limited to the resources and actions necessary for a legitimate purpose.

For doctoral-level cybersecurity practice, the central challenge is not simply selecting an identity platform. It is designing an assurance system that balances security, privacy, usability, resilience, regulatory obligations, and organizational productivity. This chapter examines that challenge through identity governance, authentication, authorization, federation, privileged-access management, access-control models, adaptive access, and zero-trust architecture.

Learning Objectives

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

1. Explain the relationship among identity, authentication, authorization, accountability, and access governance.

2. Evaluate authentication methods and identity federation architectures.

3. Design RBAC, ABAC, and hybrid authorization approaches for complex organizations.

4. Develop privileged-access and identity-lifecycle controls.

5. Apply adaptive access principles and zero-trust architectural models.

6. Analyze usability, privacy, operational, and identity-related risks.

7. Propose governance and assurance measures for enterprise and research environments.

The Identity Security Problem

An identity is a representation of an entity—such as a person, service, device, application, organization, or autonomous agent—that can be recognized by a system. Identity is not equivalent to a username. A useful identity record may include attributes, affiliations, credentials, devices, roles, entitlements, risk indicators, and historical events. Digital identity is also contextual: the same individual may possess distinct identities in employment, research, healthcare, and personal environments.

Four concepts must be distinguished. Identification is the claim of an identity, such as entering an account name. Authentication tests that claim using evidence. Authorization determines what an authenticated subject may do. Accountability connects actions to a sufficiently reliable identity and records evidence for later investigation. Confusing these stages produces weak designs—for example, treating successful authentication as justification for unrestricted authorization.

An identity assurance level expresses confidence that an identity belongs to the claimed entity and that its authenticators remain under that entity’s control. Assurance depends on identity proofing, credential strength, authenticator binding, recovery processes, and session controls. A highly reliable login can still result in unsafe access if authorization is excessive or if the endpoint is compromised.

Identity governance provides the policies, ownership, review mechanisms, and evidence needed to ensure that access remains appropriate. It addresses questions such as: Who approved this entitlement? Why does the user still require it? What happens when employment or project membership ends? Can the organization demonstrate compliance without retaining unnecessary personal information?

Authentication: Evidence, Assurance, and Usability

Authentication factors are commonly grouped as knowledge, possession, and inherence. Passwords and memorized secrets are knowledge factors; hardware security keys, smart cards, and registered mobile devices are possession factors; biometric characteristics are inherence factors. Multi-factor authentication (MFA) combines independent factors, reducing the consequences of a stolen password. However, not every two-step process is equally strong. A password followed by a code delivered through a channel controlled by an attacker may provide less assurance than phishing-resistant cryptographic authentication.

Public-key credentials, including those used by contemporary passkey systems, can bind authentication to a service and device or authenticator. They reduce password reuse and make remote credential replay more difficult. Hardware-backed keys can further protect private keys from extraction. Biometrics may improve convenience, but they are not secret in the same sense as a password; a compromised biometric characteristic cannot simply be changed. Biometric systems therefore require presentation-attack detection, template protection, fallback controls, and careful proportionality analysis.

Authentication design must include enrollment, recovery, revocation, replacement, and exception handling. Account recovery is frequently weaker than the primary login and thus becomes an attractive attack path. Security questions, help-desk overrides, emergency accounts, and device replacement procedures require formal controls, strong evidence, separation of duties, and monitoring.

Usability is a security variable. Excessive prompts can produce habituation, unsafe workarounds, and approval fatigue. Inaccessible authentication can exclude users with disabilities or users working in low-connectivity environments. A mature design uses risk-sensitive controls: strong phishing-resistant authentication for sensitive operations, carefully governed alternatives for exceptional circumstances, and transparent user communication.

Authorization and Access-Control Models

Authorization is a policy decision, not merely a technical permission assignment. It should specify the subject, resource, action, purpose, context, and applicable constraints. A policy allowing a researcher to read a dataset does not necessarily authorize copying it, exporting it, or combining it with another restricted dataset.

Role-based access control (RBAC) assigns permissions to roles and users to roles. Roles can represent job functions, project responsibilities, or operational duties. RBAC is administratively intelligible and works well where responsibilities are stable. Its weaknesses include role explosion, difficulty representing temporary conditions, and the tendency for inherited permissions to accumulate. Role engineering should begin with business activities and separation-of-duties requirements rather than with existing technical groups.

Attribute-based access control (ABAC) evaluates attributes of subjects, resources, actions, and environments. A policy might permit a clinician to view a record when the clinician is assigned to the case, the purpose is treatment, the device meets security requirements, and the request occurs within an approved session. ABAC expresses context more precisely than basic RBAC, but it depends on accurate, timely, and trustworthy attributes. Poor attribute quality can make a sophisticated policy unreliable.

Policy-based access control commonly uses a policy administration point, policy decision point, policy enforcement point, and policy information point. The decision point evaluates policy and relevant attributes; the enforcement point permits or blocks the request; information points supply trusted context. This separation supports consistent decisions across applications, APIs, service meshes, and data platforms.

Most large organizations require a hybrid model. RBAC can provide understandable baseline entitlements, while ABAC can constrain those entitlements by device posture, location, time, transaction risk, data sensitivity, or purpose. Least privilege should be treated as a continuous optimization problem: the organization seeks sufficient access for legitimate work while minimizing unnecessary capability and exposure.

Identity Lifecycle and Governance

The identity lifecycle generally includes joiner, mover, and leaver events. A joiner receives an identity and approved baseline access; a mover experiences changes caused by role, department, project, or location; a leaver must have access removed or suspended promptly. The mover case is especially problematic because organizations often add new permissions without removing obsolete ones, creating entitlement accumulation.

Identity governance platforms can connect human-resources systems, directories, applications, ticketing systems, and privileged-access systems. Automated provisioning through standardized interfaces reduces manual error, but automation can also propagate inaccurate source data at scale. The authoritative source for each identity attribute must therefore be defined, and synchronization failures must generate alerts rather than silently creating inconsistent states.

Access reviews should be risk-based rather than ceremonial. Reviewers need meaningful information about the resource, privilege, business purpose, last use, sensitivity, and consequences of approval. A manager may be unable to evaluate a technical permission without assistance from an application owner or data custodian. High-risk entitlements should receive more frequent and independent review. Certification records must preserve evidence of decision, reviewer, rationale, and remediation.

Governance also includes segregation of duties. A person who requests, approves, implements, and audits a sensitive privilege may be able to conceal misuse. Conflicting combinations—such as creating a supplier and approving payment—should be prevented or subjected to compensating controls. Governance is not achieved by technology alone; it requires accountable owners, documented policy, exception management, and auditability.

Federation and Distributed Trust

Identity federation allows one domain to rely on authentication or identity assertions issued by another. A service provider may accept an assertion from an identity provider, while an organization may use a cloud service without creating a separate password account for every user. Federation reduces credential duplication and can support single sign-on, but it introduces dependencies and trust relationships that must be governed.

Federation design must establish who issues assertions, what claims are released, how assertions are protected, how audiences and lifetimes are restricted, and how trust is revoked. Excessive attribute release can violate privacy principles and increase breach impact. Claims should be minimized to what the relying service requires. Administrative accounts, service identities, and high-risk applications may require authentication controls stronger than those used for ordinary workforce access.

Modern identity systems commonly use browser-based and API-oriented federation protocols. Regardless of protocol, critical issues include token validation, issuer and audience checking, signature verification, nonce and replay protection, secure redirect handling, key rotation, clock management, and logout or revocation limitations. A valid token can still be dangerous when it contains excessive privileges or is accepted by an unintended service.

Privileged-Access Management

Privileged accounts can alter configurations, access sensitive data, create identities, disable controls, or affect large populations. Privileged-access management (PAM) reduces this risk through account discovery, credential vaulting, just-in-time elevation, approval workflows, session monitoring, command controls, and rapid revocation.

A mature PAM program avoids permanent administrator rights wherever feasible. A user may receive a narrowly scoped privilege for a defined task and duration, with the request linked to a ticket or operational purpose. Emergency access should be time-limited, strongly authenticated, independently reviewed, and automatically recorded. Shared accounts are particularly problematic because they weaken attribution; if unavoidable, they require vaulting, checkout controls, individual authentication, and detailed session evidence.

PAM must include non-human privileged identities such as cloud service principals, automation accounts, certificates, API keys, and machine credentials. Secrets should not be embedded in source code or static configuration. Rotation, workload identity, short-lived tokens, and hardware-backed key protection can reduce exposure. Monitoring should identify unusual elevation, impossible travel, anomalous commands, access outside maintenance windows, and changes to security policy.

From Network Perimeters to Zero Trust

Zero trust is an architectural approach, not a single product and not the claim that trust can be eliminated. It assumes that network location is insufficient evidence of legitimacy. Before granting access, the organization evaluates identity, device, application, resource, request context, and risk. Access is explicitly authorized, narrowly scoped, continuously or periodically reevaluated, and logged.

A zero-trust architecture separates policy decision from policy enforcement and places enforcement close to resources. It commonly combines identity providers, endpoint-management systems, application gateways, network segmentation, data protection, analytics, and security monitoring. Microsegmentation limits lateral movement, while application-level authorization prevents the network from becoming the sole basis for access.

Zero trust should be implemented incrementally. Organizations first inventory identities, applications, data flows, devices, and dependencies. They then protect high-value applications and privileged pathways, strengthen authentication, remove obsolete access, instrument policy decisions, and expand controls based on evidence. A “replace the perimeter” project without asset visibility, identity quality, or operational telemetry is likely to create complexity rather than assurance.

Adaptive access evaluates changing signals such as authentication strength, device health, geolocation anomalies, user behavior, resource sensitivity, transaction value, and threat intelligence. A low-risk read request may be permitted, while a high-value export requires reauthentication, managerial approval, a managed device, or a secure workspace. Adaptive systems should be explainable enough for administrators and users to understand decisions and challenge false positives.

Applied Case: A Research University Adopts Zero Trust

Background

This illustrative case concerns Northbridge University, a research institution operating laboratories, student systems, clinical collaborations, and cloud-based learning services. Its environment contained multiple directories, thousands of external collaborators, legacy laboratory instruments, and research data subject to contractual and privacy restrictions.

Situation and Problem

An audit found that departing researchers retained access to project repositories, several laboratories used shared administrator accounts, and remote access was permitted after simple password authentication. Network location was treated as evidence of trust. The university could not reliably identify who had approved access to sensitive datasets, and incident investigators could not always associate actions with individual users.

Analysis

The university mapped identities, applications, data classifications, and trust relationships. It discovered that the principal risk was not a single weak control but the interaction of stale affiliations, excessive privileges, unmanaged devices, weak recovery procedures, and poorly governed external accounts. A complete denial of remote access was rejected because it would obstruct international collaboration and emergency research operations.

Approach and Strategy

The university established a central identity provider with phishing-resistant MFA for staff, administrators, and sensitive research users. Student and collaborator authentication was risk-tiered. Human-resources and research-administration systems became authoritative sources for employment and project affiliation. Access packages were created for defined research roles, with automatic expiration at project end.

RBAC provided baseline research roles, while ABAC policies considered dataset classification, project membership, device posture, purpose, and export operation. Privileged administration was moved to a PAM platform using just-in-time elevation and recorded sessions. Legacy instruments were isolated through segmentation and accessed through controlled gateways. A security operations team monitored unusual access, repeated denied requests, privilege escalation, and bulk downloads.

Outcome

The program reduced standing privilege and improved the university’s ability to demonstrate why access existed. Researchers retained remote productivity through managed workflows rather than unrestricted network access. Some legacy systems could not support modern authentication, so compensating controls—gateway enforcement, dedicated accounts, network isolation, and enhanced monitoring—were documented as exceptions.

Learning Points

The case illustrates that zero trust is an organizational transformation involving data owners, human resources, research administrators, infrastructure teams, and users. It also shows that exceptions are inevitable, but undocumented exceptions become permanent weaknesses. Identity quality, lifecycle automation, and meaningful telemetry were as important as MFA.

Risks, Limitations, and Common Errors

Identity systems create concentration risk. If the primary identity provider is unavailable or compromised, many applications may be affected. Resilience therefore requires redundant services, protected administrative paths, recovery procedures, tested break-glass accounts, and independent monitoring. Centralization improves consistency but can create a high-value target.

Common failures include deploying MFA without addressing recovery, treating all MFA as phishing-resistant, assigning broad roles for convenience, failing to remove mover entitlements, trusting directory attributes without validation, and assuming that a successful login proves a safe session. Organizations also overuse conditional-access rules without testing their effects on service accounts, accessibility, emergency operations, and international travel.

Risk scoring and behavioral analytics can produce false positives, discrimination, or opaque decisions. Security teams should validate models, monitor disparate impacts, minimize collected data, define retention periods, and provide human review for consequential decisions. Continuous verification should not mean continuous surveillance of every aspect of a person’s life.

Service outages and lockouts are also security events. Availability, safety, and mission continuity must be included in access design. A control that prevents legitimate emergency treatment, industrial maintenance, or disaster response may create risks greater than those it addresses. Exception processes should be rapid but accountable.

Ethics, Regulation, and Professional Responsibility

Identity governance involves personal data, including affiliations, behavioral records, device information, and sometimes biometrics. Collection must have a legitimate purpose, be proportionate, protected against misuse, and retained only as long as necessary. Data minimization and purpose limitation should influence both architecture and analytics.

Organizations should explain authentication and access decisions in understandable language. They should provide accessible alternatives, avoid discriminatory assumptions based on location or behavioral patterns, and ensure that contractors and international collaborators are not subjected to arbitrary exclusion. Consent alone is not a complete ethical justification when users have little practical choice.

Professional responsibility includes accurate audit evidence, honest treatment of exceptions, protection of administrator credentials, and prompt disclosure of identity-related incidents. Governance frameworks and privacy or sectoral regulations may impose requirements for access reviews, logging, breach response, records protection, and individual rights. Compliance is a baseline; an organization must still evaluate whether its controls are effective in its own threat and mission context.

Automation, Analytics, and Emerging Developments

Automation can provision and deprovision accounts, evaluate policy, rotate secrets, detect anomalous behavior, and generate access-review recommendations. Infrastructure-as-code and policy-as-code improve repeatability and enable testing before deployment. Automated decisions must include safeguards against stale attributes, policy conflicts, cascading errors, and unauthorized changes.

Artificial intelligence is increasingly used to identify abnormal authentication patterns, cluster entitlements, summarize access reviews, and recommend least-privilege changes. These applications can assist experts but should not be treated as inherently reliable. Training-data bias, adversarial manipulation, weak explanations, and automation bias can turn recommendations into new risks. High-impact access decisions require validation, traceability, and human accountability.

Emerging identity environments include workload identities for cloud-native applications, decentralized identity claims, passwordless authentication, confidential computing, and identity for autonomous agents. Agent identities will require explicit ownership, constrained capabilities, delegated authority, expiry, provenance, and human or system-level approval boundaries. The fundamental problem remains unchanged: a system must determine which entity is acting, what it may do, and why that action is justified.

Design Principles and Best Practices

Effective programs generally follow these principles:

• Establish authoritative identity sources and define ownership for every important attribute and entitlement.
• Prefer phishing-resistant MFA for privileged and high-impact access, with secure recovery and tested alternatives.
• Combine understandable roles with contextual attributes rather than forcing every decision into one model.
• Remove standing privilege and use time-limited, task-specific elevation.
• Treat joiner, mover, and leaver processes as security controls, not administrative conveniences.
• Place enforcement near applications and data, not solely at the network perimeter.
• Log authentication, authorization, elevation, policy changes, and administrative actions with reliable time and identity context.
• Test policies against legitimate workflows, failure conditions, accessibility needs, and emergency scenarios.
• Minimize identity data, protect it rigorously, and make automated decisions reviewable.
• Measure outcomes through stale-account rates, entitlement age, privileged-session coverage, MFA resistance, deprovisioning time, unauthorized-access events, false-positive rates, and recovery performance.

Chapter Summary

Identity security links the representation of entities with authentication, authorization, accountability, and governance. Strong assurance requires more than passwords or MFA: it depends on reliable identity proofing, secure lifecycle management, appropriate authorization, protected recovery, and trustworthy evidence. RBAC offers administrative clarity, ABAC provides contextual precision, and hybrid models often best reflect organizational complexity. Federation can simplify access while introducing dependencies that require careful trust and claim governance. PAM limits the impact of powerful accounts through just-in-time elevation, vaulting, monitoring, and control of non-human credentials. Zero trust rejects implicit trust based on network location and continuously evaluates access in relation to identity, device, resource, context, and risk. Its success depends on visibility, usable controls, resilience, privacy, and accountable governance. Automation and AI can improve scale and detection, but they require validation, transparency, and human responsibility.

Key Terms

Identity: A representation of an entity that can be recognized by an information system.

Identification: A subject’s claim about which identity it represents.

Authentication: Verification of a claimed identity using one or more credentials or factors.

Authorization: The decision about which actions an authenticated subject may perform.

Accountability: The ability to associate actions with a responsible identity and reliable evidence.

Identity governance: Policies and processes that control identity lifecycle, entitlements, ownership, and review.

Multi-factor authentication: Authentication using independent categories of evidence.

Phishing-resistant authentication: Authentication designed to resist credential capture and replay through service-bound cryptographic mechanisms.

Federation: A trust arrangement in which one domain accepts identity assertions from another.

RBAC: Access control based primarily on roles assigned to users or entities.

ABAC: Access control based on attributes of subjects, resources, actions, and context.

Least privilege: Limiting an identity to the minimum access necessary for legitimate tasks.

Segregation of duties: Separation of conflicting responsibilities to reduce fraud and error.

Privileged-access management: Controls for discovering, restricting, elevating, monitoring, and revoking powerful accounts.

Just-in-time access: Temporary access granted for a defined task and period.

Adaptive access: Authorization that changes according to contextual and risk signals.

Zero trust: An architecture that rejects implicit trust and evaluates every access request explicitly.

Policy enforcement point: A component that permits, blocks, or constrains a request according to an authorization decision.

Identity lifecycle: The processes governing identity creation, modification, suspension, and removal.

Workload identity: An identity assigned to software, services, or automated processes.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accountability.

2. Why can account recovery undermine an otherwise strong authentication system?

3. What is the principal difference between RBAC and ABAC?

4. Explain the purpose of just-in-time privileged access.

5. Why does zero trust reject network location as sufficient evidence of trust?

Long Answer Questions

1. Explain how identity governance manages joiner, mover, and leaver risks.

2. Compare RBAC, ABAC, and hybrid authorization for a large research institution.

3. Discuss the architecture and governance requirements of identity federation.

4. Design a PAM program for a cloud-based enterprise, including human and non-human identities.

5. Critically evaluate the relationship between usability, privacy, and authentication assurance.

Analytical / Application Questions

1. A contractor changes projects but retains access to the first project’s sensitive repository. Analyze the governance failure and propose controls.

2. A hospital wants adaptive access based on device health, location, and user behavior. Design a policy approach that protects patients without obstructing emergency care.

3. An organization has strong MFA but experiences repeated unauthorized data exports by legitimate users. Use zero-trust and authorization principles to diagnose and redesign the control environment.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication assigns permissions, while authorization verifies identity.

B. Authentication verifies a claimed identity, while authorization determines permitted actions.

C. Authentication records events, while authorization encrypts credentials.

D. Authentication creates roles, while authorization removes accounts.

Correct Answer: B. Authentication verifies a claimed identity, while authorization determines permitted actions.

Question 2

A university permits a researcher to access a dataset only when the researcher belongs to the approved project, uses a managed device, and specifies an approved purpose. Which approach is most evident?

A. Basic discretionary access control

B. Role-only access control

C. Attribute-based access control

D. Anonymous access control

Correct Answer: C. Attribute-based access control

Question 3

Which control most directly addresses entitlement accumulation when employees change jobs?

A. Increasing password length

B. Automated mover processes that reassess and remove obsolete access

C. Allowing permanent administrator rights

D. Disabling access reviews

Correct Answer: B. Automated mover processes that reassess and remove obsolete access

Question 4

What is a principal security advantage of phishing-resistant, cryptographic authentication?

A. It eliminates the need for authorization policies.

B. It makes biometric data changeable after compromise.

C. It reduces the usefulness of captured passwords and replayed credentials.

D. It guarantees that a device is free of malware.

Correct Answer: C. It reduces the usefulness of captured passwords and replayed credentials.

Question 5

Which PAM design most closely follows least privilege?

A. Permanent domain administrator access for all IT staff

B. A shared administrator password stored in a spreadsheet

C. Time-limited elevation for an approved task with session recording

D. Disabling logs to improve administrator performance

Correct Answer: C. Time-limited elevation for an approved task with session recording

Question 6

In a federated identity system, why should claims be minimized?

A. To prevent the identity provider from authenticating users

B. To reduce unnecessary privacy exposure and limit information available to relying services

C. To ensure every application receives a complete personnel record

D. To eliminate the need for token validation

Correct Answer: B. To reduce unnecessary privacy exposure and limit information available to relying services

Question 7

Which statement best represents zero-trust security?

A. All internal network users are trusted after connecting through the corporate VPN.

B. Access is explicitly evaluated using identity, resource, context, and risk rather than network location alone.

C. Only external users require authentication.

D. Perimeter firewalls are sufficient if they block internet traffic.

Correct Answer: B. Access is explicitly evaluated using identity, resource, context, and risk rather than network location alone.

Question 8

A policy decision point determines that a request is allowed. Which component should technically apply that decision to the requested resource?

A. Policy enforcement point

B. Human-resources system

C. Identity proofing office

D. Credential recovery desk

Correct Answer: A. Policy enforcement point

Question 9

Why can behavioral analytics in adaptive access create governance concerns?

A. They cannot process any access logs.

B. They may produce opaque, biased, or false-positive decisions and collect sensitive personal data.

C. They always grant excessive privileges.

D. They eliminate the need for human review in high-impact decisions.

Correct Answer: B. They may produce opaque, biased, or false-positive decisions and collect sensitive personal data.

Question 10

A legacy laboratory instrument cannot support modern MFA. Which response is most consistent with a mature zero-trust program?

A. Place it on the unrestricted internal network.

B. Ignore the weakness because the instrument is old.

C. Use compensating controls such as gateway enforcement, isolation, dedicated accounts, and enhanced monitoring.

D. Give every researcher permanent administrator access.

Correct Answer: C. Use compensating controls such as gateway enforcement, isolation, dedicated accounts, and enhanced monitoring.