COMP 6660 · Enterprise Cybersecurity Identity and Access Management

00 Introduction

The first four lessons of Unit 2 addressed the cryptographic technologies that protect data and establish trust. This lesson addresses the discipline that determines who is allowed to do what: identity and access management.

Identity and access management — IAM — is the set of processes and technologies used to create, manage, and govern digital identities and their access to enterprise resources. It answers the fundamental question that underlies every enterprise security decision: who is this, and what are they permitted to do?

IAM has become the primary control plane of the modern enterprise. In an era when workloads run in clouds the enterprise does not own, users work from locations the enterprise does not control, and services are consumed from third parties the enterprise does not administer, network location is no longer a useful basis for trust. Identity has taken its place. Access decisions are increasingly made based on who is requesting, from what device, in what context — not on whether the request originates from inside some privileged perimeter.

This lesson examines IAM as an architectural discipline rather than as a product category. It introduces the concepts and vocabulary of enterprise identity; examines the identity lifecycle from creation through retirement; addresses provisioning and de-provisioning — the operations that determine whether access is granted when needed and removed when it is not; explains directory services and federation; examines privileged access management as a distinct discipline; and closes with identity governance, IAM architecture, and the failures that recur across enterprise IAM programmes.

The material here prepares directly for Lesson 2.6, which examines authentication and authorization models in detail, and for Lesson 2.7, which develops Zero Trust — the architectural paradigm that places identity at the centre of enterprise security.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 2 outcomes U2.2 (authentication technologies) and U2.4 (identity management), and to Module 1 outcome M1.12 (IAM design and governance). See the Unit 2 learning outcomes page for the full mapping.

02 What IAM is and why it matters

Identity and access management is the discipline through which an enterprise establishes, maintains, and governs the relationship between subjects (users, services, devices) and resources (data, systems, applications). It answers three questions continuously and at scale:

• Who is this? Establishing the identity of a subject — authentication.
• What are they permitted to do? Determining the actions a subject is authorised to perform — authorization.
• How do we know? Producing a reliable record of what subjects did, when, and under what authority — accountability and audit.

Why identity has become the primary control plane

For most of the history of enterprise IT, access was controlled primarily through network location. Systems trusted requests that came from inside the corporate network and did not trust those that came from outside. Identity mattered — but location mattered more.

Enterprise digitisation, as Lesson 1.1 argued, has dissolved that perimeter. Workloads run in clouds the enterprise does not own; employees work from home, from mobile devices, and from partner premises; services are consumed from third parties whose networks are not the enterprise's. There is no meaningful "inside" from which requests can be trusted.

In this environment, identity is what remains. Access decisions must be made on the basis of who is requesting, from what device, in what context, against what resource — not on the basis of network location. This is why IAM has moved from a support function to a strategic capability, and why modern enterprise architectures increasingly organise around identity rather than around networks.

Why IAM matters for enterprise security

03 Identity concepts

IAM operates on a small set of core concepts. Understanding them precisely is important because they are frequently confused, and because the confusion produces design errors.

Human and non-human identities

Enterprise identity management historically focused on human users. The modern estate contains a substantial population of non-human identities: service accounts, API keys, workload identities, device identities, and machine credentials. In many enterprises, non-human identities now outnumber human ones by a significant margin.

Non-human identities present distinct challenges:

• They are often unmanaged. Service accounts, API keys, and workload credentials are frequently created outside formal IAM processes and not inventoried.
• They often have excessive privilege. Service accounts are commonly granted broad access because the effort of fine-grained authorization is not applied.
• They are difficult to rotate. Rotating credentials for a service account requires coordinating with every system that uses it, discouraging rotation.
• They are attractive targets. Compromise of a service account or workload identity often grants access to substantial enterprise resources without triggering user-focused detection.
• They persist indefinitely. Human identities have natural lifecycles (employment); non-human identities often persist long after the application or process that used them is retired.

Addressing non-human identity is now one of the most active areas in enterprise IAM. The development of workload identity platforms, secret management services, and short-lived credential issuance reflects the recognition that non-human identities require their own governance discipline — distinct from, but analogous to, the discipline applied to human identities.

04 The identity lifecycle

An identity is not a static object. It is created, used, modified, and eventually retired. The identity lifecycle describes these stages and the operations associated with each. Managing the lifecycle is one of the most consequential activities in enterprise IAM.

05 Provisioning and de-provisioning

Provisioning and de-provisioning are the operational activities through which the identity lifecycle is managed. They are among the highest-value targets for automation in enterprise IAM, because manual processes do not scale and are not timely.

Provisioning

Provisioning is the process of creating identities and granting them the entitlements they require. It occurs in response to business events — hiring, contracting, service deployment, device enrolment — and its purpose is to ensure that subjects have the access they need to perform their function.

Provisioning approaches vary in automation and rigour:

De-provisioning

De-provisioning is the process of removing access when it is no longer needed. It occurs in response to departure, role change, project completion, service retirement, or device decommissioning. Its purpose is to ensure that access does not persist beyond its legitimate need.

De-provisioning is often more difficult than provisioning, for several reasons:

• Coverage is hard. An identity may have accounts in dozens of systems. Removing all of them requires that all be known and reachable.
• Trigger reliability varies. De-provisioning depends on timely notification of the event. HR notifications are reliable; project-completion notifications often are not.
• Exceptions are common. Departing employees may retain limited access for transition purposes, creating ambiguity about what to remove and when.
• Non-human identities are often excluded. Service accounts associated with a departed employee may not be identified as belonging to that individual.
• Verification is difficult. Proving that access has been removed everywhere is more difficult than proving that it was granted.

Privilege creep and access review

Provisioning grants access; de-provisioning removes it. Over time, the two operations do not balance: access is added as responsibilities grow but is rarely removed when those responsibilities end. The result is privilege creep — a gradual accumulation of entitlements that no longer matches the subject's function.

Access review (sometimes called access recertification) is the governance mechanism through which privilege creep is addressed. Periodically — monthly, quarterly, or annually depending on sensitivity — access is reviewed by managers, system owners, or the subjects themselves, and unnecessary access is removed. Reviews are documented and auditable.

Access review is demanding. Reviews that are not genuinely performed become rubber stamps that provide the appearance of control without substance. The value of review depends entirely on whether reviewers examine entitlements critically and whether removal actually happens.

06 Directory services

A directory service is a system that stores and manages information about identities, resources, and their relationships. It is the repository on which enterprise IAM depends — the system that holds the authoritative record of who exists, what attributes they have, and what entitlements they hold.

Roles of a directory service

• Storage. Holds identity records, attributes, and group or role memberships.
• Authentication. Provides the mechanism through which subjects authenticate. In some deployments, the directory is also the authentication service; in others, authentication is delegated to a separate identity provider that references the directory.
• Directory queries. Provides a standard interface — LDAP is the dominant protocol — through which applications query identity information.
• Policy storage. Holds group policies, access policies, and configuration that is distributed to managed systems.
• Trust relationships. Maintains trust relationships between directories in different domains or forests, enabling authentication and authorization across them.

Enterprise directory services

Directory design considerations

Directory services are foundational infrastructure. Design decisions have long-term consequences, and re-architecting a directory is a substantial undertaking. Key considerations include:

• Single directory versus multiple. A single directory simplifies management but concentrates risk. Multiple directories can isolate sensitive populations but increase complexity and require cross-directory trust.
• On-premises, cloud, or hybrid. Cloud directories provide scalability and integration with cloud services; on-premises directories remain relevant for legacy systems and for environments with strict data residency requirements.
• Schema design. The directory schema defines what attributes can be stored and how. Schema changes propagate widely and must be planned carefully.
• Trust relationships. Cross-domain and cross-forest trusts enable authentication across directory boundaries but extend the blast radius of a compromise.
• Replication and availability. Directory services must be highly available; authentication failure means the enterprise stops working. Replication topology and availability design are critical.
• Privileged access to the directory. Directory administrators have effective control over everything the directory governs — which is to say, most of the enterprise. Protection of directory administrative access is a highest-priority security concern.

07 Federation

Federation is the mechanism by which an identity established in one security domain is trusted in another. It enables authentication and authorization to span organisational and technical boundaries, and it is central to how modern enterprises integrate applications, partners, and cloud services.

What federation solves

Without federation, every application would require its own identity store and its own authentication mechanism. Users would need separate accounts for every system, and administrators would need to manage identities in dozens of places. Federation eliminates this duplication by allowing an identity established once to be used across many systems.

Federation also enables cross-organisational identity. When a customer signs in to a service using their employer's identity, or when an enterprise grants its partners access to a partner portal, federation provides the mechanism. The identity is established by one party (the identity provider) and consumed by another (the service provider).

How federation works

Federation is built on a trust relationship between an identity provider and a service provider. The identity provider authenticates the subject and issues an assertion — a signed statement about the subject's identity and attributes. The service provider consumes the assertion and makes an access decision based on the information it contains.

The assertion is signed by the identity provider, allowing the service provider to verify its authenticity. This is why PKI — Lesson 2.4 — is prerequisite for federation: the trust relationship between IdP and SP is built on cryptographic trust.

Federation standards

Single sign-on

Federation enables single sign-on (SSO) — the property that a subject authenticates once and gains access to multiple applications without re-authenticating. SSO is one of the most visible benefits of federation, and one of the most consequential for enterprise security.

SSO improves security in several respects: it reduces the number of credentials users must manage, which reduces password reuse and weak passwords; it centralises authentication, allowing consistent policies to be applied; and it makes de-provisioning easier, because disabling an identity in the IdP revokes access to every application the IdP serves.

SSO also concentrates risk. If a subject's SSO credentials are compromised, the attacker gains access to every application the SSO covers. This makes the protection of SSO credentials — through strong authentication, multi-factor authentication, and session management — correspondingly more important.

Federation trust considerations

Federation extends trust across boundaries, and the enterprise's security posture is affected by the trustworthiness of the identity providers it accepts. Useful considerations include:

• Which identity providers does the enterprise trust? Each trusted IdP can assert identities to the enterprise's service providers. The strength of the IdP's authentication and governance determines the strength of the enterprise's own access control.
• How is the IdP authenticated? The cryptographic trust relationship between IdP and SP must be established and maintained — typically through certificate exchange.
• What attributes are asserted? The attributes the IdP provides determine the authorization decisions the SP can make. Where attributes are insufficient, SPs may need to maintain additional identity data.
• What happens when the IdP is unavailable? Federation creates dependency. If the IdP is down, access to every federated service may be affected.
• How is the trust relationship terminated? When federation is no longer needed — a partner relationship ends, a service is retired — the trust relationship must be removed. Lingering trust relationships are a common governance gap.

08 Privileged access management

Privileged access management (PAM) is the discipline of controlling, monitoring, and governing access held by administrative and privileged accounts. It is treated as a distinct discipline within IAM because privileged access is qualitatively different from ordinary access — and because failures of privileged access management are disproportionately consequential.

What makes privileged access different

• Scope of impact. A privileged account can often affect every system it governs. Compromise of a single privileged account can compromise the entire enterprise estate.
• Bypass of controls. Privileged accounts can often disable logging, modify security controls, and access data without triggering ordinary detection.
• Centrality to the enterprise. Privileged accounts often manage the infrastructure on which other controls depend — directories, identity systems, cloud management planes. Compromise propagates further.
• Concentration of trust. The number of privileged accounts is typically small relative to the total population, but the trust placed in them is disproportionate.

Categories of privileged account

PAM capabilities

PAM programmes typically combine several capabilities, each addressing a distinct risk:

The principle of standing privilege minimisation

Traditional enterprise administration granted administrators standing privilege — they held privileged access continuously, whether or not they were actively using it. This creates continuous exposure: if their account or workstation is compromised at any time, the attacker gains the privilege.

Modern PAM practice minimises standing privilege. Administrators are ordinary users most of the time and obtain elevated access only when needed, for a defined period, through a controlled process. Elevation is logged, monitored, and time-bounded. The result is that compromise of an administrator's ordinary account does not immediately yield privileged access, and compromise of a privileged session is limited to the duration of that session.

09 Identity governance

Identity governance is the set of policies, processes, and controls through which the enterprise ensures that access is granted appropriately, reviewed regularly, and removed when no longer needed. It is the discipline that keeps IAM honest over time.

What identity governance addresses

• Who can grant access? The authority to grant entitlements should be defined, bounded, and auditable. Granting access is itself a privileged operation.
• How is access requested and approved? Requests for access should be captured, evaluated against policy, and approved by appropriate parties. Approvals should be logged.
• How is access reviewed? Periodic review ensures that entitlements remain appropriate. Reviews should be documented and should produce real action — removal of access that is no longer needed.
• How is access removed? Termination, transfer, and role change should trigger removal of superseded access. Removal should be timely and verifiable.
• How is access audited? The enterprise should be able to demonstrate, for any subject, what access they hold, how it was granted, when it was reviewed, and what they have done with it.
• How are exceptions managed? Some access will not fit normal patterns. Exceptions should be explicit, time-bounded, and reviewed more frequently than standard access.

Governance mechanisms

Role-based access control as a governance mechanism

Role-based access control (RBAC), examined in more depth in Lesson 2.6, is both an authorization model and a governance mechanism. By organising entitlements into roles that reflect business functions, RBAC simplifies the assignment and review of access. Reviewers can reason about roles rather than about individual entitlements, which makes access reviews tractable at scale.

Effective RBAC requires well-designed roles. Roles that are too broad accumulate excessive entitlements; roles that are too granular are difficult to administer. Role design is an ongoing discipline, and it is one of the areas where identity governance intersects with organisational design.

The governance trap

Identity governance can slide into a documentation exercise in which reviews are conducted but no changes result, and reports are produced but not acted on. The trap is that the mechanisms exist, the processes are followed, and the enterprise believes it is governed — but the substantive outcome is unchanged.

The antidote is to measure outcomes, not activity. The relevant questions are not "were reviews conducted?" but "was inappropriate access removed?" Not "were requests approved?" but "were approvals justified and were the resulting entitlements appropriate?" Governance that does not produce change is not governance.

10 Enterprise IAM architecture

Enterprise IAM is not a single product but a collection of components, processes, and integrations. A coherent architecture makes the components work together; an incoherent one produces gaps, duplication, and inconsistency.

Reference components

Design considerations

• Authoritative source clarity. Each attribute should have a single authoritative source. Ambiguity about which system is authoritative produces inconsistency.
• Integration coverage. IAM is only as effective as its coverage. Systems that are not integrated with the IAM infrastructure must be managed manually — and often are not.
• Identity lifecycle alignment. IAM architecture should reflect the identity lifecycle. Provisioning, modification, and de-provisioning should be automated wherever possible, and triggered by reliable events.
• Authentication and authorization separation. The architecture should distinguish clearly between establishing identity (authentication) and deciding what that identity may do (authorization). Conflating them produces inconsistency.
• Governance integration. Governance mechanisms — access review, request workflows, certification — should be integrated into the architecture, not bolted on later.
• Cloud and on-premises consistency. Where the enterprise operates both, the architecture should provide consistent identity and access across them. Hybrid complexity is a common source of inconsistency.
• Support for non-human identities. The architecture should address service accounts, workload identities, and device identities as first-class citizens, not as exceptions.

11 IAM failures and lessons

IAM failures recur across enterprises. Recognising the patterns accelerates assessment and informs improvement.

Failure pattern 1 — Orphaned accounts

Accounts whose owners have departed but whose credentials remain valid and whose access is not removed. Orphaned accounts are a recurring source of enterprise breach because they provide unmonitored access that no one is responsible for.

Lesson: De-provisioning must be automated and triggered by reliable events. Manual processes produce orphans.

Failure pattern 2 — Privilege creep

Entitlements accumulate over time as responsibilities grow, with removal happening rarely if at all. Subjects end up with substantially more access than their current function requires.

Lesson: Access reviews must produce removals. Reviews that approve everything are not reviews.

Failure pattern 3 — Unmanaged privileged access

Privileged accounts used without vaulting, session brokering, or recording. Credentials stored in configuration files or administrator memory. Administrators with standing privilege they rarely use.

Lesson: Privileged access management is a distinct discipline and must be treated as such. The concentration of risk in privileged accounts is disproportionate.

Failure pattern 4 — Excessive trust in federation

Trust relationships established with external identity providers without adequate assessment of the provider's controls, without scoping the trust to what it was intended to support, and without periodic review.

Lesson: Each federated trust relationship is an extension of the enterprise's security boundary. It should be governed accordingly.

Failure pattern 5 — Non-human identity blind spots

Service accounts, API keys, and workload identities that exist outside formal IAM processes. Frequently over-privileged, rarely rotated, and not included in access reviews.

Lesson: Non-human identities require the same governance discipline as human identities. Their population is growing and their exposure is frequently underestimated.

Failure pattern 6 — Directory compromise

Compromise of a directory service — most commonly Active Directory in on-premises environments — which provides the attacker with effective control over the enterprise estate.

Lesson: Directory services and their administrative accounts warrant the strongest controls in the enterprise. Directory compromise should be treated as a catastrophic event with a pre-planned response.

Failure pattern 7 — Governance theatre

Governance mechanisms that exist on paper but do not produce change. Reviews that approve everything; approvals that are not examined; reports that are not read.

Lesson: Governance should be measured by outcomes, not by activity. The relevant question is not whether reviews were conducted but whether access was appropriately adjusted.

12 Key concepts

The terms below are used throughout the course. Capture them in your own words as you work through the lesson.

Identity and access management (IAM)

The set of processes and technologies used to create, manage, and govern digital identities and their access to enterprise resources. Answers who the subject is, what they may do, and how we know.

Digital identity

The representation of a subject within the enterprise's identity systems. Consists of identifiers, credentials, and attributes.

Subject

The entity whose identity is represented — a human user, a service account, a workload, or a device.

Identifier

A unique label by which a subject is known within a system.

Credential

Evidence used to authenticate a subject — a password, an API key, a certificate, a biometric sample, or a hardware token.

Attribute

A property associated with a subject — department, role, manager, location, clearance, device posture. Used in authorization decisions, particularly in attribute-based access control.

Entitlement

A specific permission or access right granted to a subject.

Role

A collection of entitlements associated with a job function or set of responsibilities. The primary mechanism through which entitlements are assigned in role-based access control.

Identity provider (IdP)

A system that creates, maintains, and authenticates identities.

Service provider (SP)

An application or service that relies on an identity provider for authentication and receives assertions about the identity of subjects.

Identity lifecycle

The stages through which an identity passes — provisioning, setup, ongoing use, modification, de-provisioning, and archival or deletion.

Provisioning

The process of creating identities and granting them the entitlements they require, typically in response to a business event.

De-provisioning

The process of removing access when it is no longer needed — on departure, role change, or service retirement. Timeliness is critical.

Privilege creep

The gradual accumulation of entitlements that no longer matches the subject's function, produced by access being added but rarely removed.

Access review / recertification

Periodic review of entitlements to confirm their continued appropriateness. Reviews should produce removals; reviews that approve everything are not reviews.

Directory service

A system that stores and manages information about identities, resources, and their relationships. Common examples include Active Directory, Entra ID, and LDAP-based directories.

Federation

The mechanism by which an identity established in one security domain is trusted in another. Enables single sign-on and cross-organisational identity.

Single sign-on (SSO)

The property that a subject authenticates once and gains access to multiple applications without re-authenticating. Enabled by federation.

SAML, OIDC, OAuth

Federation and authorization standards. SAML is XML-based and mature; OIDC is built on OAuth 2.0 and uses JSON tokens; OAuth 2.0 is an authorization framework enabling delegated access.

Privileged access management (PAM)

The discipline of controlling, monitoring, and governing access held by administrative and privileged accounts. Includes credential vaulting, session brokering, recording, just-in-time access, and rotation.

Standing privilege

Privileged access held continuously by an administrator, whether or not it is in active use. Modern PAM practice minimises standing privilege.

Just-in-time access

Privileged access granted on demand for a defined period and revoked automatically. Reduces standing privilege and limits the window of exposure.

Identity governance

The policies, processes, and controls through which the enterprise ensures that access is granted appropriately, reviewed regularly, and removed when no longer needed.

Separation of duties

The principle that combinations of entitlements that would allow a single subject to complete a sensitive operation alone should be prevented.

Non-human identity

An identity representing a service account, workload, API, or device rather than a human user. Increasingly outnumbers human identities and presents distinct governance challenges.

Orphaned account

An account whose owning identity is no longer active but whose credentials remain valid and whose access is not removed.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 1. They are not graded, but completing them will improve the quality of your forum contribution.

14 Self-check

Answer the questions below before moving to Lesson 2.6. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined identity and access management as an architectural discipline. The essential points are:

• IAM answers who, what, and how we know. It establishes identity, determines what a subject may do, and produces the record of what they did. It has become the primary control plane of the enterprise because digitisation dissolved the perimeter.
• Core identity concepts include digital identity, identifiers, credentials, attributes, entitlements, and roles. Non-human identities — service accounts, workload identities, devices — are an increasingly significant population and require distinct governance.
• The identity lifecycle is the framework for managing identity over time. Provisioning, setup, use, modification, de-provisioning, and archival or deletion. Each stage has its own operational and security considerations.
• Provisioning grants access; de-provisioning removes it. Over time, the two operations do not balance, and privilege creep results. Access review is the governance mechanism through which creep is addressed.
• Directory services are the repository on which enterprise IAM depends. Active Directory, Entra ID, Okta, and others. Compromise of a directory service is among the most consequential events an enterprise can experience.
• Federation extends trust across domains. Enables SSO and cross-organisational identity. SAML and OIDC are the dominant standards. Each federated trust relationship is an extension of the enterprise's security boundary.
• Privileged access management is a distinct discipline. Privileged accounts have disproportionate impact. Modern PAM includes vaulting, session brokering, recording, just-in-time access, rotation, and monitoring.
• Identity governance keeps IAM honest. Access request workflows, certification, separation-of-duties analysis, and reporting. Governance should be measured by outcomes, not by activity.
• IAM failures follow predictable patterns. Orphaned accounts, privilege creep, unmanaged privileged access, excessive trust in federation, non-human identity blind spots, directory compromise, and governance theatre.

These ideas prepare for Lesson 2.6, which examines the authentication and authorization models — RBAC and ABAC — through which access decisions are made within the enterprise.