Identity, Access and Human-Centric Security

Introduction and Context

Information security is increasingly an identity problem. Traditional perimeter security assumed that users, devices, applications, and data operated inside a relatively trusted organisational network. Cloud computing, remote work, mobile access, software-as-a-service, application programming interfaces, and business partnerships have weakened that assumption. A user may access several services from an unmanaged device, through a third-party identity provider, from a changing network location. Consequently, security decisions must be based on verified identity, contextual risk, explicit authorisation, and continuous monitoring rather than network location alone.

Identity, access and human-centric security connects technical controls with organisational behaviour and governance. It includes identity governance, authentication, authorisation, federation, privileged access management, zero-trust architecture, social-engineering resistance, insider-risk management, and security awareness. These areas are interdependent. Strong authentication is ineffective if accounts are not reviewed. A precise authorisation model is undermined by excessive privileges. Security awareness is insufficient if systems are designed to encourage unsafe workarounds.

This chapter treats access as a socio-technical process. Technology establishes controls, but policies, incentives, management decisions, culture, and human judgement determine how those controls operate in practice.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Explain the identity lifecycle and the distinction between identification, authentication, authorisation, and accountability.

2. Design identity governance processes for joiners, movers, leavers, access reviews, and segregation of duties.

3. Compare authentication factors, adaptive authentication, federation, and modern passwordless approaches.

4. Apply role-based, attribute-based, and risk-adaptive authorisation models.

5. Design privileged access and zero-trust controls.

6. Analyse social engineering, insider threats, and the human factors that produce security failures.

7. Evaluate identity programmes using technical, operational, ethical, and governance criteria.

1. Identity as a Security and Governance Domain

An identity is a representation of a person, service, device, or other entity that can be recognised by an information system. An account is a technical record associated with an identity; credentials are evidence used to authenticate it. These terms should not be treated as interchangeable.

Four foundational activities are distinct:

• Identification: claiming an identity, such as entering a username.
• Authentication: providing evidence that the claimant controls the identity.
• Authorisation: determining what the authenticated entity may do.
• Accountability: associating actions with an identity through logging and monitoring.

A useful security objective is least privilege: an entity receives only the access necessary for an authorised task, for only as long as necessary. Least privilege is not identical to simply giving users fewer permissions. It requires understanding business tasks, dependencies, emergency procedures, and the consequences of denying legitimate work.

Identity governance extends access administration into policy and oversight. It answers questions such as: Who owns an application? Who may approve access? Which access combinations create fraud risk? How quickly must leavers be disabled? What evidence demonstrates that access was reviewed? Governance therefore links identity technology to risk appetite, regulatory duties, internal controls, and auditability.

Identity Lifecycle

The lifecycle generally contains the following stages:

1. Registration and proofing: establishing that an identity corresponds to a real person or legitimate entity.

2. Provisioning: creating accounts and assigning initial access.

3. Maintenance: changing access when job duties, projects, locations, or risk conditions change.

4. Review and recertification: requiring owners or managers to confirm that access remains appropriate.

5. Suspension: temporarily disabling access during investigation, leave, or unusual activity.

6. Deprovisioning: removing access when employment, contract, or business need ends.

7. Record retention and audit: preserving evidence in accordance with legal and organisational requirements.

The joiner–mover–leaver model is operationally important. Joiner processes should be timely but should not grant broad default access. Mover processes are often neglected: an employee may retain permissions from previous roles, creating privilege accumulation. Leaver processes must be coordinated across directories, applications, tokens, remote sessions, physical access, service accounts, and third-party platforms.

Identity governance benefits from authoritative sources, usually a human-resources or workforce-management system for employees and a supplier or contract-management system for external workers. Automated provisioning through standards such as SCIM can improve consistency, but automation does not eliminate the need for ownership, exception handling, or review.

2. Authentication and Assurance

Authentication factors are commonly grouped into:

• Something the user knows: a password or memorised secret.
• Something the user has: a hardware security key, smart card, or registered device.
• Something the user is: a biometric characteristic.

Multifactor authentication uses evidence from two or more independent factor categories. Two passwords are not multifactor authentication because both are knowledge factors. A biometric usually verifies a binding between a person and a device or system; it is not a secret that can simply be replaced if compromised. Biometric systems should therefore include privacy protection, liveness detection where appropriate, fallback procedures, and proportionality analysis.

Passwords and Password Managers

Passwords remain common because they are inexpensive and widely supported, but they are vulnerable to reuse, phishing, credential stuffing, guessing, malware, and data breaches. Organisations should prevent known-compromised passwords, support password managers, rate-limit authentication attempts, protect password databases with slow salted password hashing, and avoid unnecessary periodic changes that encourage predictable variations. Passwords should be replaced by stronger methods where feasible, rather than merely surrounded by complex composition rules.

Multifactor and Phishing Resistance

One-time passwords delivered by text message or generated by an application reduce some risks, but they may remain vulnerable to phishing, malware, or real-time relay. Hardware-backed cryptographic authenticators, including passkeys based on public-key credentials, can provide stronger phishing resistance because authentication is bound to the legitimate service origin. The private key remains protected by the authenticator while the service stores a public key rather than a reusable password.

Recovery is a critical part of authentication design. A strong primary method can be defeated by a weak account-recovery process. Recovery should use identity proofing, independent evidence, risk-based delays, notifications, and controlled help-desk procedures. Support personnel should not reset credentials solely because a caller supplies easily discoverable personal information.

Adaptive Authentication

Adaptive authentication evaluates context such as device health, location, time, transaction value, network reputation, behavioural patterns, and sensitivity of the resource. A low-risk activity may require normal authentication, while an unusual high-value transfer may require a phishing-resistant authenticator and transaction confirmation. Adaptive controls should be explainable enough to support legitimate users and should be tested for discriminatory effects or excessive false positives.

Authentication assurance is not the same as certainty. Every method has failure modes, including stolen devices, coercion, account recovery abuse, implementation defects, and compromised endpoints. Security architecture should therefore combine authentication with authorisation, monitoring, device controls, and incident response.

3. Authorisation Models

Authorisation determines permitted operations on specified resources under defined conditions. A complete access decision includes at least a subject, an action, a resource, and a context. For example, a clinician may read a patient record during an assigned shift, but may not export the entire database.

Access Control Principles

Important principles include:

• Least privilege: minimise permissions and duration.
• Need to know: limit access to information required for a task.
• Separation of duties: divide conflicting responsibilities.
• Default deny: reject access unless a policy explicitly permits it.
• Fail safely: errors should not silently grant access.
• Complete mediation: check access on every relevant operation, not only at login.
• Dual control: require two authorised parties for especially sensitive actions.

Role-Based Access Control

Role-based access control assigns permissions to roles and users to roles. Roles should describe business responsibilities rather than individuals. A well-designed role catalogue reduces administrative complexity and improves reviewability. However, excessive role granularity can create role explosion, while overly broad roles produce excessive privilege. Role engineering should analyse actual tasks, resource sensitivity, approval responsibilities, and incompatible combinations.

Segregation-of-duties analysis can identify conflicts such as the same person creating a supplier and approving payment. Preventive controls block the conflict; detective controls identify it for investigation. Emergency or break-glass access should be time-limited, strongly logged, independently reviewed, and restricted to defined circumstances.

Attribute- and Policy-Based Access

Attribute-based access control evaluates attributes of the subject, resource, action, and environment. Examples include department, clearance, data classification, device compliance, geographic region, and time. Policy-based systems can express rules such as: a finance employee may approve an invoice only when the employee did not create it, the device is compliant, and the transaction is below a defined threshold.

Attribute-based approaches are flexible but depend on accurate, trusted, and current attributes. A wrong department attribute can produce a wrong access decision. Policy decisions should therefore be versioned, tested, monitored, and subject to change control.

Access Reviews

Access recertification should be risk-based. Privileged, financial, production, and sensitive personal-data access normally requires more frequent review than low-risk general access. Reviewers need meaningful information: the permission, business purpose, recent use, resource owner, and consequences of removal. A superficial approval button is not an effective control. Unused access can be a useful signal, but lack of recent use alone does not prove that access is unnecessary because some roles are exercised infrequently.

4. Federation and Distributed Identity

Federation allows one domain to trust authentication assertions issued by another. A workforce member may authenticate through an organisational identity provider and access a cloud application without maintaining a separate application password. Federation can reduce password duplication, improve central policy enforcement, and simplify deprovisioning.

Common conceptual roles are:

• Identity provider: authenticates the subject and issues an assertion or token.
• Service provider or relying party: consumes the assertion and provides a service.
• Subject: the person or entity represented by the assertion.
• Trust relationship: technical and contractual arrangements that define acceptable assertions.

Federation introduces concentration and trust risks. A compromised identity provider can affect many applications. Poor audience restriction, token validation, signing-key management, clock handling, or logout design can create vulnerabilities. Organisations should minimise token claims, protect signing keys, validate issuer and audience, define token lifetimes, monitor unusual federation activity, and establish responsibilities for incidents.

Federation is also relevant to business-to-business access and machine identities. Service accounts, workload identities, application credentials, and API tokens require owners, rotation or short lifetimes, scoped permissions, and monitoring. They should not be treated as invisible technical details merely because no human directly logs in.

5. Privileged Access Management

Privileged accounts can alter security controls, data, infrastructure, and audit records. Examples include domain administrators, cloud tenancy administrators, database administrators, root accounts, security operators, and high-impact application administrators. Privilege is contextual: an ordinary account may be highly sensitive in a particular application.

A mature privileged access management programme includes:

• Separate administrative accounts from routine user accounts.
• Elimination of shared administrator credentials where possible.
• Vaulting of secrets and controlled checkout.
• Just-in-time and just-enough access.
• Strong multifactor authentication.
• Approval and ticket linkage for high-risk actions.
• Session recording or command logging where lawful and proportionate.
• Workstation and endpoint hardening for administration.
• Emergency access with post-event review.
• Continuous discovery of privileged accounts and secrets.

The objective is not surveillance for its own sake. It is to reduce the probability and impact of misuse while preserving evidence for troubleshooting and investigation. Excessive monitoring may damage trust or infringe privacy; controls should therefore be transparent, proportionate, access-controlled, and governed by retention rules.

6. Zero-Trust Access

Zero trust is an architectural approach in which no user, device, application, or network location is automatically trusted. Access is explicitly requested, evaluated against policy, and continuously or repeatedly assessed according to risk. It does not mean that trust is mathematically reduced to zero, nor does it require eliminating all network boundaries.

A practical zero-trust decision includes:

1. Subject identity and authentication assurance.

2. Device identity, security posture, and health.

3. Resource sensitivity and transaction type.

4. Environmental context and threat intelligence.

5. Policy, business purpose, and applicable constraints.

6. Logging, monitoring, and response capability.

Zero trust is often implemented through identity-aware proxies, micro-segmentation, device-management platforms, strong application authentication, policy engines, and continuous telemetry. Its success depends on accurate inventories, reliable identity data, application modernisation, and clear ownership. A poorly governed zero-trust programme can simply create more policy complexity and more opportunities for incorrect denial or accidental exposure.

7. Social Engineering and Human-Centric Security

Social engineering manipulates people into disclosing information, transferring value, bypassing controls, installing malicious software, or granting access. Techniques include phishing, spear phishing, business-email compromise, pretexting, baiting, impersonation, tailgating, vishing, smishing, and deepfake-assisted fraud.

The attacker often exploits authority, urgency, scarcity, fear, helpfulness, familiarity, or cognitive overload. A secure response cannot depend on perfect attention. Organisations should design processes that make safe behaviour easy: independent verification of payment changes, clear reporting channels, protected approval workflows, technical filtering, browser and email protections, and procedures that do not punish employees for reporting mistakes.

Awareness training is more effective when it is role-specific, continuous, and connected to actual workflows. Mandatory annual modules may satisfy a formal requirement but seldom create durable competence. Simulated exercises should be ethical, proportionate, and used for learning rather than humiliation. Metrics should include reporting speed, quality of escalation, repeat patterns, and control improvements, not merely click rates.

8. Insider Threats and Organisational Resilience

An insider threat is the potential for a person with legitimate access to cause harm intentionally or unintentionally. Insiders may be employees, contractors, suppliers, or compromised users. Motivations include financial gain, grievance, ideology, coercion, negligence, and convenience.

A balanced programme distinguishes malicious insider activity from ordinary human error. Controls include least privilege, monitoring of high-risk actions, data-loss prevention, secure offboarding, peer review, conflict-of-interest controls, anonymous reporting, fair disciplinary processes, and support for stressed or targeted personnel. Behavioural indicators should never be treated as proof of wrongdoing. Security teams must avoid profiling based on protected characteristics, personal beliefs, or lawful activity.

Insider-risk programmes require cooperation among security, human resources, legal, privacy, compliance, and management. Data collection should have a defined purpose, limited access, retention controls, and procedural safeguards. Investigations should preserve evidence while respecting due process.

9. Governance, Privacy and Regulation

Identity programmes process sensitive personal information, including names, employment details, device identifiers, authentication events, biometrics, and behavioural records. Governance must address purpose limitation, data minimisation, accuracy, retention, access rights, transparency, and lawful processing. Biometrics and continuous behavioural analytics require particularly careful justification because compromise or misuse can have lasting consequences.

Accountability should be assigned through policies and control ownership. A useful governance structure identifies executive sponsorship, identity-service ownership, application owners, data owners, access approvers, privacy specialists, internal audit, and incident responders. Policies should define exceptions, review frequency, evidence requirements, and consequences for non-compliance.

Regulatory obligations differ by jurisdiction and sector, but common expectations include access control, authentication appropriate to risk, logging, timely deprovisioning, protection of sensitive data, vendor oversight, and incident response. Compliance is not equivalent to security. A control may satisfy an audit requirement while failing against a new attack technique or an unsafe business process.

10. Measuring an Identity and Human-Centric Security Programme

Useful measures combine outcomes, exposure, efficiency, and user experience. Examples include:

• Percentage of workforce accounts governed by an authoritative lifecycle source.
• Time to disable leaver accounts and revoke active sessions.
• Percentage of privileged access that is just-in-time.
• Number and age of unresolved segregation-of-duties conflicts.
• Percentage of sensitive applications using phishing-resistant authentication.
• Rate of successful and timely access recertification.
• Number of orphaned, shared, dormant, or unknown accounts.
• Mean time to investigate suspicious access.
• Security-reporting rate and time to report suspected phishing.
• Help-desk recovery fraud attempts and authentication failure patterns.

Metrics require interpretation. A rise in reported phishing may indicate better awareness rather than more attacks. A low click rate in a simulation may reflect unrealistic scenarios. A short deprovisioning time measured only in the central directory may conceal active sessions in cloud systems. Mature measurement therefore combines quantitative indicators with sampling, interviews, audit findings, incident analysis, and user feedback.

11. Applied Case: Illustrative Regional Health Network

Background

A fictional regional health network operates hospitals, clinics, laboratories, and a cloud-based patient-record platform. Doctors, nurses, contractors, students, and external specialists need different levels of access. The organisation experienced three problems: former contractors retained accounts, clinicians used shared emergency credentials, and a convincing payment-fraud email reached the finance department.

Problem Analysis

An initial review found that the human-resources system was not connected to several clinical applications. Managers approved access without seeing recent use or the exact permissions involved. Emergency accounts were not consistently reviewed. Multifactor authentication protected remote access but not all internal clinical applications. The payment-fraud incident was enabled by an email change request that bypassed independent verification.

The organisation also discovered that some clinical roles combined record access with broad export privileges. This created both privacy risk and the possibility of unauthorised bulk disclosure. The problem was therefore not simply insufficient training; it involved lifecycle design, authorisation, workflow, and governance.

Approach and Solution

The network established an identity governance board and assigned application and data owners. Workforce status became the authoritative trigger for joiner, mover, and leaver workflows. Clinical roles were redesigned using least privilege and separation of duties. Bulk export required a separate role, a documented business purpose, and enhanced logging.

Phishing-resistant authentication was introduced for administrators and remote high-risk access, with a staged plan for clinical systems. Privileged access was separated from routine accounts and granted through time-limited elevation. Emergency access remained available for patient-safety situations but required a reason code, notification, and retrospective review.

The finance department introduced an independent callback procedure using a trusted directory rather than contact details in the request. Awareness activities used realistic, role-specific exercises and emphasised rapid reporting without blame. Monitoring correlated identity, device health, unusual location, bulk access, and privileged activity.

Outcome

The network reduced orphaned accounts, improved leaver control, identified dormant privileges, and increased the speed of suspicious-email reporting. Some users initially objected to additional authentication and emergency-access review. The governance board addressed this by simplifying legitimate workflows, providing clinical support, and distinguishing safety-critical access from convenience access. The programme did not eliminate risk, but it reduced opportunities for misuse and improved the organisation’s ability to detect and investigate abnormal activity.

Learning Points

1. Identity failures often arise from disconnected organisational processes rather than a single defective product.

2. Access reviews are effective only when reviewers receive understandable evidence.

3. Emergency access should be controlled, not eliminated where availability is safety-critical.

4. Human-centred design improves security adoption and reduces unsafe workarounds.

5. Technical controls, workflow verification, governance, and culture must be implemented together.

12. Contemporary Developments and Critical Issues

Passwordless authentication, passkeys, continuous access evaluation, confidential computing, decentralised identity, and identity threat detection are important developments. Their value depends on deployment conditions. Passwordless systems still require secure enrolment, device recovery, accessibility provisions, and support against social engineering. Decentralised identity may reduce dependence on a central provider, but it introduces questions about issuer trust, revocation, wallet security, and user privacy.

Artificial intelligence can assist with identity anomaly detection, access-review prioritisation, phishing analysis, and policy conflict discovery. It can also create risks: biased risk scores, opaque denials, false positives, automated account suspension, deepfake-enabled impersonation, and leakage of identity data into external models. AI should support human decision-making rather than become an unreviewable authority for employment, access, or disciplinary decisions. Models require documented purpose, representative evaluation, adversarial testing, change control, explainability appropriate to the decision, and an appeal path.

Best-Practice Design Principles

A professional identity and human-centric security programme should:

• Establish authoritative identity sources and clear ownership.
• Automate lifecycle events while retaining exception and audit processes.
• Prefer phishing-resistant authentication for high-value access.
• Separate authentication from authorisation and evaluate both continuously where justified.
• Apply least privilege, default deny, separation of duties, and time-limited elevation.
• Protect privileged and machine identities as carefully as human accounts.
• Use federation deliberately, with strong token validation and trust governance.
• Design zero-trust policies around identity, device, resource, context, and evidence.
• Make reporting and verification easy for employees.
• Treat awareness as a behavioural and organisational programme, not a yearly quiz.
• Measure outcomes and unintended consequences, not only compliance activity.
• Protect privacy, ensure proportionality, and provide human review for consequential decisions.

Chapter Summary

Identity and access management is a governance discipline as well as a technical capability. Identification, authentication, authorisation, and accountability perform different functions and must be designed together. The identity lifecycle governs registration, provisioning, movement, review, suspension, and deprovisioning. Strong programmes use authoritative sources, least privilege, segregation of duties, meaningful access reviews, and careful treatment of privileged and machine identities.

Authentication assurance depends on factor independence, phishing resistance, secure recovery, and contextual evaluation. Federation can simplify access but creates concentrated trust and token-management risks. Zero trust replaces implicit network trust with explicit, contextual, and continually evaluated decisions. Human-centric security addresses social engineering, insider threats, behaviour, workflow design, and organisational culture. Awareness, monitoring, and AI-supported detection are valuable only when privacy, fairness, explainability, and human oversight are maintained.

The central professional lesson is that identity security succeeds when technology, governance, business process, and human behaviour reinforce one another.

Key Terms

Identity: A representation of a person, device, service, or entity.

Authentication: Verification of a claimant’s control of an identity.

Authorisation: Determination of permitted actions on resources.

Accountability: Association of actions with an identifiable entity.

Identity governance: Policies, ownership, oversight, and evidence governing identities and access.

Least privilege: Granting only the access necessary for an authorised task.

Multifactor authentication: Authentication using independent factor categories.

Phishing-resistant authentication: Authentication designed to resist credential capture and relay through origin-bound or cryptographic methods.

Federation: Mutual trust enabling one domain to accept identity assertions from another.

Identity provider: A service that authenticates subjects and issues assertions or tokens.

Role-based access control: Access control based on assigned organisational roles.

Attribute-based access control: Access control based on subject, resource, action, and environmental attributes.

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

Privileged access management: Controls for discovering, limiting, monitoring, and governing elevated access.

Zero trust: An architecture that avoids implicit trust and evaluates access explicitly.

Social engineering: Manipulation of people to obtain access, information, or action.

Insider threat: Potential harm caused by a person with legitimate organisational access.

Joiner–mover–leaver process: Lifecycle management for entering, changing, and leaving an organisation.

Break-glass access: Exceptional emergency access subject to strong logging and review.

Identity threat detection: Monitoring and analysis of identity activity for compromise or misuse.

Review Questions

Short Answer Questions

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

2. Why are mover processes important in the identity lifecycle?

3. Explain why two passwords do not constitute multifactor authentication.

4. State two benefits and two risks of identity federation.

5. What is the purpose of segregation of duties?

Long Answer Questions

1. Explain how an organisation should design joiner, mover, and leaver processes, including governance and audit requirements.

2. Compare role-based access control with attribute-based access control and discuss when each is appropriate.

3. Describe a privileged access management programme for a cloud-based enterprise.

4. Explain zero-trust access and analyse its relationship with identity, device posture, and continuous monitoring.

5. Discuss how security awareness, workflow design, and organisational culture can reduce social-engineering risk.

Analytical / Application Questions

1. A contractor changes from database development to customer support but retains database-export permissions. Analyse the control failures and propose a lifecycle and access-review solution.

2. A bank wants to use AI to suspend accounts after anomalous behaviour. Design safeguards addressing false positives, privacy, explainability, human review, and appeals.

3. A hospital must preserve emergency access while preventing misuse of shared credentials. Develop an authentication, authorisation, logging, and retrospective-review design.

Multiple Choice Questions with Answers

Question 1

Which activity determines what an authenticated user is permitted to do?

A. Identification

B. Authentication

C. Authorisation

D. Registration

Correct Answer: C. Authorisation

Question 2

Which option is a phishing-resistant authentication method?

A. A reused password

B. A hardware-backed origin-bound security key

C. A password sent by email

D. A static security question

Correct Answer: B. A hardware-backed origin-bound security key

Question 3

Why is a mover process important?

A. It creates anonymous accounts

B. It removes the need for authentication

C. It prevents users from retaining inappropriate former-role access

D. It eliminates all access reviews

Correct Answer: C. It prevents users from retaining inappropriate former-role access

Question 4

Which principle requires access to be denied unless explicitly permitted?

A. Default deny

B. Open trust

C. Maximum availability

D. Role explosion

Correct Answer: A. Default deny

Question 5

What is a major risk of poorly governed federation?

A. It prevents all central policy enforcement

B. Compromise of the identity provider can affect many relying applications

C. It makes tokens impossible to validate

D. It eliminates the need for application owners

Correct Answer: B. Compromise of the identity provider can affect many relying applications

Question 6

Which control is most characteristic of just-in-time privileged access?

A. Permanent administrator rights for all engineers

B. Time-limited elevation for an approved task

C. A shared administrator password

D. Unlogged emergency access

Correct Answer: B. Time-limited elevation for an approved task

Question 7

What does zero-trust architecture reject?

A. All forms of encryption

B. Explicit access policies

C. Implicit trust based solely on network location

D. Device security assessment

Correct Answer: C. Implicit trust based solely on network location

Question 8

Which example best illustrates segregation of duties?

A. One employee creates and approves the same supplier payment

B. Two independent employees create and approve a payment

C. All employees receive administrator access

D. A user changes a password

Correct Answer: B. Two independent employees create and approve a payment

Question 9

Which measure is most useful for evaluating leaver control?

A. Number of awareness posters

B. Time required to disable accounts and revoke active sessions

C. Number of office locations

D. Length of the password policy

Correct Answer: B. Time required to disable accounts and revoke active sessions

Question 10

Which statement about insider threats is most accurate?

A. They involve only malicious employees

B. They can include intentional and unintentional harm by people with legitimate access

C. They are eliminated by annual training

D. They should be assessed using protected personal characteristics

Correct Answer: B. They can include intentional and unintentional harm by people with legitimate access