Zero Trust: Identity and Access Management

Table of Contents

• Module 1: Understanding the Concepts of Identity and Access Management in a Zero Trust Architecture
  • Understanding Identity
  • Understanding Authentication, Authorization, and Accounting
  • Implementing Identity Verification and Authentication
• Module 2: Understanding MFA in Zero Trust Environments
  • Understanding Authentication Factors
  • Demo: Introducing Zero Trust and MFA into Cloud-based Systems
  • Implementing Least Privilege on Security Accounts
• Module 3: Understanding IAM Lifecycle Management
  • Understanding Account Creation
  • Understanding Account Deprovisioning
  • Demo: Creating and Managing Accounts
• Summary

This reference manual covers identity and access management (IAM) as it applies within a Zero Trust architecture: the terminology of identity, authentication, authorization, and accounting (IAAA); the authentication factors that make up multi-factor authentication (MFA); conditional access and least-privilege enforcement mechanisms such as just-in-time (JIT) and just-enough access (JEA); and the full IAM lifecycle from account creation through deprovisioning, including automated lifecycle workflows in the cloud.

Module 1: Understanding the Concepts of Identity and Access Management in a Zero Trust Architecture

This module builds the foundational vocabulary needed to reason about IAM in a Zero Trust context: what an identity actually is, how authentication, authorization, and accounting (IAAA) fit together, and how identity verification has evolved from legacy on-premises directory services to federated and cloud-native identity providers aligned with NIST SP 800-207.

Understanding Identity

Within identity and access management, identity is formally defined as a set of claims about a subject. A subject is any entity that may need to gain access to a resource — this could be a person/user, a device, an application, or an entire organization.

A subject can carry multiple attributes that identify it, including:

• A name or username
• A job title or organizational role
• A physical feature (facial recognition, fingerprint, retinal scan — i.e., biometrics)
• A date of birth, physical location, or address
• Something the subject possesses, such as an ID card

These identifying attributes are the raw material used during the authentication and authorization process — a topic explored in depth in the multi-factor authentication (MFA) discussion later in this document, where more than one attribute (factor) is combined to authenticate a subject.

Because these attributes frequently constitute personally identifiable information (PII), the identity itself must be kept secure, and its handling typically falls under compliance obligations. This information is usually stored and managed by an identity provider (IdP), which is the entity responsible for the authentication and authorization process.

flowchart TD
    A[Subject] -->|has| B[Identity = a set of claims]
    B --> C1[Name / Username]
    B --> C2[Job Title / Role]
    B --> C3[Physical Feature<br/>Biometrics]
    B --> C4[Date of Birth / Location]
    B --> C5[Possession<br/>ID Card / Token]
    C1 & C2 & C3 & C4 & C5 --> D[Personally Identifiable Information]
    D --> E[Stored/Managed by an<br/>Identity Provider - IdP]
    E --> F[Used in Authentication<br/>and Authorization]

Understanding Authentication, Authorization, and Accounting

With identity defined, the next layer of concepts moves toward access management itself, built on three pillars — authentication, authorization, and accounting, together forming IAAA when combined with identity.

• Authentication — the process where a subject proves its identity to a system. The subject presents one or more attributes; each attribute used in this process is called a factor. Using more than one factor is the foundation of two-factor or multi-factor authentication (MFA), covered in Module 2.
• Authorization — once authenticated, a subject is granted access to a resource through an allocated set of permissions, which determine which actions the subject may perform on that resource (for example, read and write access to files on a file server).
• Accounting — every access event must be logged. Accounting supports auditing and compliance, helps maintain resource availability, and provides the evidentiary trail needed during security investigations.

To manage authorization, administrators commonly use one of several access control models:

Combining identity, authentication, authorization, and accounting produces the classic security acronym IAAA, which underpins most modern security frameworks — including Zero Trust.

The three defining tenets of a Zero Trust architecture are:

1. Never trust
2. Always verify
3. Assume breach

A key enforcement principle running through all of Zero Trust is least-privilege access — not a new idea in security, but a non-negotiable feature of any Zero Trust implementation. Zero Trust has gained significant traction as organizations shift toward remote and hybrid workforces, mobile and IoT devices, bring-your-own-device (BYOD) policies, and cloud-based services. All of this is underpinned by the classic CIA triad — confidentiality, integrity, and availability — which governs the data-protection and risk posture of the organization.

flowchart LR
    subgraph IAAA[IAAA Model]
        I[Identity] --> A1[Authentication<br/>Prove identity]
        A1 --> A2[Authorization<br/>Grant permissions]
        A2 --> A3[Accounting<br/>Log & audit]
    end
    IAAA --> ZT[Zero Trust Architecture]

mindmap
  root((Zero Trust Core Tenets))
    Never Trust
      No implicit trust for any subject
      Applies inside and outside the perimeter
    Always Verify
      Continuous authentication/authorization
      Context-aware policy checks
    Assume Breach
      Design as if attackers are already present
      Minimize blast radius
    Least Privilege
      Minimum permissions necessary
      Underpins every access decision
    Drivers
      Remote/hybrid workforces
      Mobile & IoT / BYOD
      Cloud-based services
      CIA triad - confidentiality, integrity, availability

Implementing Identity Verification and Authentication

Before cloud-native identity, organizations relied on on-premises directory services such as Active Directory Domain Services (AD DS), underpinned by the Kerberos authentication protocol. Active Directory evolved to support federated services, using claims to let subjects access resources beyond their own trusted domain, and enabling single sign-on (SSO) so a subject only needs to remember one set of credentials.

Kerberos authentication and authorization flow (within a trusted domain):

1. The subject (user) authenticates against a Domain Controller (the authenticating server).
2. The subject then requests access to a resource, such as a file server.
3. Before granting access, the resource validates the request against the Key Distribution Center (KDC) on the Domain Controller.
4. This three-way trust relationship — subject, resource, and KDC — is where Kerberos gets its name (the three-headed dog of Greek mythology).

sequenceDiagram
    participant U as Subject (User)
    participant DC as Domain Controller<br/>(Authenticating Server / KDC)
    participant FS as Resource<br/>(e.g., File Server)

    U->>DC: 1. Authenticate (logon)
    DC-->>U: Ticket-Granting Ticket (TGT)
    U->>FS: 2. Request access to resource
    FS->>DC: 3. Validate authentication/authorization<br/>with Key Distribution Center
    DC-->>FS: Confirmation
    FS-->>U: 4. Access granted (trust established)

While effective inside a single organization, this model becomes unmanageable when remote users need access to external resources. This is where federated identity takes over: an external, federated trust is established between the on-premises domain controller and online resources.

flowchart LR
    subgraph OnPrem[Trusted On-Premises Domain]
        DC[Domain Controller / KDC]
        FS[Internal File Server]
    end
    subgraph External[External / Federated Resources]
        FedSvc[Federated Service]
        CloudRes[Cloud Resource]
    end
    User((Subject)) --> DC
    DC -- Federated Trust --> FedSvc
    FedSvc --> CloudRes
    User -.SSO.-> CloudRes

Legacy on-premises trust models — while functional — are difficult to administer, particularly for remote users. This has driven adoption of cloud-based identity and access management systems, including Microsoft Azure/Entra ID, AWS, Google Cloud, and Okta. Public identity providers such as Google, Facebook, and Apple are also widely used, enabled by open standards:

A subject already holding a trust relationship with an identity provider (e.g., an existing Google or Facebook account) can use that relationship to sign in to a resource, rather than creating a brand-new account. The resource only needs a restricted subset of the subject’s attributes — the identity provider does not need to disclose the full attribute set.

sequenceDiagram
    participant User as Subject
    participant Resource as Resource / Application
    participant IdP as External Identity Provider<br/>(Google / Facebook / Apple)

    User->>Resource: Request access
    Resource-->>User: Offer: create account OR sign in via IdP
    User->>IdP: Authenticate (SAML / OIDC / OAuth)
    IdP-->>Resource: Restricted set of claims/attributes
    Resource-->>User: Access granted

When these components are layered into a Zero Trust architecture, the canonical reference is NIST Special Publication 800-207, which should be treated as the authoritative reference for Zero Trust architecture solutions. Its logical architecture describes an untrusted subject on a system attempting to reach a resource, mediated by a Policy Enforcement Point (PEP), which is in turn controlled by a Policy Decision Point (PDP) that determines what access is permitted.

flowchart LR
    Subject((Subject<br/>Untrusted by default)) --> PEP[Policy Enforcement Point]
    PEP <--> PDP[Policy Decision Point]
    PDP --> ID[ID Management]
    PDP --> DAP[Data Access Policies]
    PDP --> PKI[Public Key Infrastructure]
    PEP --> Resource[(Protected Resource)]

For this course’s scope, the areas of the NIST SP 800-207 model that are most relevant are ID management, data access policies, and elements of public key infrastructure — the remaining components of the broader Zero Trust architecture are addressed in companion courses on network and application/data security.

Module 2: Understanding MFA in Zero Trust Environments

This module covers the authentication factors that combine to form MFA, walks through a hands-on demonstration of configuring Zero Trust and MFA controls in a cloud identity platform, and closes with least-privilege enforcement mechanisms such as JIT and JEA access.

Understanding Authentication Factors

Authentication factors are generally grouped into distinct types:

Multi-factor authentication (MFA) is defined as using two or more factors to authenticate a subject. Common combinations include:

• Smart card + PIN → something you have + something you know
• PIN + fingerprint → something you know + something you are
• Password + authenticator app code → something you know + something you have
• Password + authenticator app + biometric unlock of the app → something you know + something you have + something you are (true multi-factor authentication)

The shorthand 2FA refers specifically to two-factor (bifactor) authentication, while MFA more broadly refers to any combination of more than one factor. MFA has become commonplace even in consumer contexts (e.g., LinkedIn, Facebook), driven largely by the widespread insecurity of passwords alone. Within organizations, enforcing MFA is typically a mandatory account access policy.

mindmap
  root((Authentication Factors))
    Something You Know
      Username & Password
      PIN
    Something You Have
      Smart Card
      Hardware Token
      Authenticator App
    Something You Are
      Fingerprint
      Facial Recognition
      Retinal Scan
    Somewhere You Are
      Network Location
      IP Address
      Geographic Location
    Something You Do
      Gait Analysis
      Behavioral / AI-Derived Patterns

flowchart TD
    A[Single Factor<br/>e.g., Password Only] -->|Add 2nd Factor| B[Two-Factor Authentication - 2FA]
    B -->|Add 3rd Factor| C[True Multi-Factor Authentication]
    B1[Something You Know] --- B
    B2[Something You Have] --- B
    C --- C1[Something You Know]
    C --- C2[Something You Have]
    C --- C3[Something You Are]

Demo: Introducing Zero Trust and MFA into Cloud-based Systems

This walkthrough uses Microsoft Entra ID (formerly Microsoft Azure Active Directory) in the Azure portal to demonstrate MFA and conditional access configuration. The exact UI layout evolves over time across all major cloud providers, but the underlying concepts are consistent across Azure, AWS, and Google Cloud.

Step-by-step walkthrough:

1. Sign in to the Azure portal (portal.azure.com) and navigate to Microsoft Entra ID.
2. Open the Security settings, which are organized into four functional areas:
   • Troubleshooting and support
   • Reporting — covers risk detections such as risky sign-ins or risky users (e.g., a sign-in from an unusual location, or “impossible travel” where a user appears to log on from two distant locations within minutes — a strong indicator of account compromise, which Zero Trust policy can automatically block).
   • Manage — identity and access management configuration.
   • Protect — conditional access, identity protection, verified ID.
3. Under Manage → Multi-factor authentication settings, configure:
   • Account lockout thresholds
   • Blocking/unblocking users who trip a risk threshold
   • Fraud alerts and notifications
   • Phone call settings/providers and server authentication
4. Under Manage → Authentication methods, review built-in methods and (in preview) external authentication methods that can extend supported factors.
5. Under Authentication strengths, Microsoft groups MFA options into three escalating tiers:

1. Password protection policy settings allow configuration of lockout thresholds/duration, and a custom banned password list of up to 1,000 entries (e.g., geographic locations, sports teams, or the company name) to prevent weak, guessable passwords.
2. Under Protect → Named locations, configure countries or IP ranges as location-based conditions (the somewhere you are factor), which then feeds into conditional access policies.
3. Other items under Protect include:
   • Verified ID — Microsoft’s SSO solution built on open standards.
   • Security center — a consolidated portal mirroring the controls above.
   • Identity protection — review of compromised accounts and underlying detection policies.
4. Conditional access sits at the top of the Protect menu and controls access to resources for Entra ID (and other) accounts. Creating a new policy involves:
   • Naming the policy
   • Assignment — apply to all users or a specific group, with granularity based on resource classification/confidentiality
   • Conditions — network/location (IP address or GPS coordinates), sign-in risk, device risk
   • Access controls — grant access requiring MFA (or a specific authentication strength: MFA, passwordless MFA, or phishing-resistant MFA), device trust, or application-specific conditions
   • Session controls — governs session behavior for cloud applications

flowchart TD
    Start([New Conditional Access Policy]) --> Name[Name the Policy]
    Name --> Assign[Assignment: All Users or Specific Group]
    Assign --> Cond[Conditions]
    Cond --> C1[Network / Location<br/>IP or GPS]
    Cond --> C2[Sign-in Risk]
    Cond --> C3[Device Risk]
    C1 & C2 & C3 --> Grant[Access Controls]
    Grant --> G1[Require MFA]
    Grant --> G2[Require Authentication Strength:<br/>MFA / Passwordless / Phishing-resistant]
    Grant --> G3[Require Compliant/Trusted Device]
    G1 & G2 & G3 --> Session[Session Controls]
    Session --> End([Policy Enforced at Sign-in])

The following is an illustrative representation (not a verbatim export) of what such a conditional access policy looks like when expressed as a Microsoft Graph API resource, consistent with the settings configured in the portal walkthrough above:

{
  "displayName": "Require MFA for risky sign-ins",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeGroups": ["all-employees-group-id"]
    },
    "locations": {
      "includeLocations": ["All"],
      "excludeLocations": ["trusted-named-location-id"]
    },
    "signInRiskLevels": ["medium", "high"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"],
    "authenticationStrength": {
      "displayName": "Phishing-resistant MFA"
    }
  }
}

Implementing Least Privilege on Security Accounts

The least-privilege principle (also known as need-to-know, or need-to-know-in-whole) states that accounts should only be granted the minimum set of permissions necessary to perform their role or job function.

Access control models used to enforce this include:

Privileged access management (PAM) addresses a historically common failure mode: administrators being granted excessive, un-audited privileges. A frequently cited example is a systems administrator granting a teacher temporary local administrative rights to install classroom software, then forgetting to revoke that access — leaving a standing, unaudited privilege that becomes an attractive target for malicious actors.

Two mechanisms mitigate this risk:

• Just-in-Time (JIT) access — permissions are automatically revoked after a defined time window; the subject must first be authorized by an administrator to activate the access.
• Just-Enough Access (JEA) — access is scoped to only the minimum privileges required, directly implementing least privilege.

flowchart TD
    Req[User Requests Elevated Role] --> Approval{Requires Approval?}
    Approval -- Yes --> Admin[Administrator Approves]
    Approval -- No / Pre-approved --> Activate
    Admin --> Activate[Role Activated<br/>Just-in-Time]
    Activate --> Scope[Scope Limited to<br/>Just-Enough Access]
    Scope --> Timer[Activation Timer Starts<br/>e.g., 8-hour Maximum]
    Timer --> Expire[Access Automatically Revoked]
    Expire --> Audit[Logged for Auditing<br/>Discover & Monitor]

Demonstration — JIT/JEA in Microsoft Entra ID:

1. In the Microsoft Entra ID portal, navigate to Roles and administrators, which lists all administrative roles in the domain, several of which are flagged as privileged access.
2. Selecting a role (e.g., Application Administrator) shows eligible vs. active assignments, and role settings covering:
   • Activation — e.g., a maximum activation duration of 8 hours
   • Whether activation requires administrator approval
   • Assignment and notification settings
3. To assign the role to a user (e.g., “Alan”), navigate to the user’s account → Manage → Add assignment, then choose an assignment type:
   • Eligible — the user must request activation and wait for authorization before the role becomes active (if permanent, they remain permanently eligible)
   • Active with a defined start and end date/time — this is how just-in-time access is configured directly at assignment time, bounded by the role’s maximum activation threshold (e.g., 8 hours)
4. The Microsoft Entra Privileged Identity Management (PIM) platform consolidates this into three functional areas:
   • Manage access — review and grant access following least privilege
   • Activate just-in-time — self-service or admin-triggered activation
   • Discover and monitor — audit critical resource access

sequenceDiagram
    participant Admin as Administrator
    participant Portal as Entra ID Portal
    participant PIM as Privileged Identity Management
    participant Alan as User (Alan)

    Admin->>Portal: Select Role -> Application Administrator
    Portal-->>Admin: Show eligible/active assignments,<br/>8-hour max activation
    Admin->>Alan: Add assignment (Eligible or Active with start/end)
    Alan->>PIM: Request activation (if Eligible)
    PIM->>Admin: Approval request (if required)
    Admin-->>PIM: Approve
    PIM-->>Alan: Role activated (time-bound)
    Note over PIM: Discover & Monitor logs the activation<br/>for auditing purposes

An illustrative representation of a PIM eligible/active role assignment, consistent with the demo above:

{
  "principalId": "alan-user-object-id",
  "roleDefinitionId": "application-administrator-role-id",
  "assignmentType": "Eligible",
  "scheduleInfo": {
    "startDateTime": "2026-01-01T08:00:00Z",
    "expiration": {
      "type": "AfterDuration",
      "duration": "PT8H"
    }
  }
}

Module 3: Understanding IAM Lifecycle Management

This final module walks through the complete lifecycle of an identity account — creation, ongoing management, and deprovisioning — and demonstrates how cloud platforms can automate these routine but critical administrative tasks.

Understanding Account Creation

Account creation may be a manual or automated process — automation typically relies on templates or scripts. The lifecycle generally proceeds as follows:

1. Create the identity and populate its attributes (manually, or via template/script).
2. Allocate the account to groups, which grants access to resources through permissions.
3. Assign roles where applicable — either as eligible (requiring just-in-time activation) or permanently assigned, depending on job duties.
4. Once provisioned, the account starts with very little inherent trust — consistent with Zero Trust, it must go through the authentication/authorization process to establish trust.
5. Ongoing account management includes:
   • MFA administration
   • Password policy administration
   • Conditional access policy enforcement (device and application assignments included)
   • Licensing (on-premises or cloud)
   • Reset and revocation activities as routine administrative tasks

Groups are used to manage access to resources (via permissions and policies, including conditional access), while roles are used to assign administrative responsibilities — tying back into the privileged access and PIM concepts from Module 2.

flowchart TD
    A[Create Identity] --> B[Populate Attributes]
    B --> C[Allocate to Groups<br/>-> Resource Permissions]
    C --> D[Assign Roles<br/>Eligible or Permanent]
    D --> E[Account Provisioned<br/>Zero Trust: Little Inherent Trust]
    E --> F[Authenticate / Authorize<br/>to Establish Trust]
    F --> G[Ongoing Management]
    G --> G1[MFA Administration]
    G --> G2[Password Policy]
    G --> G3[Conditional Access]
    G --> G4[Licensing]
    G --> G5[Reset & Revocation]

Understanding Account Deprovisioning

Accounts (and devices) are deprovisioned for many reasons, which shape the exact process followed:

Account state progression, typically governed by organizational policy:

1. Disabled / On hold — may include a legal hold while an investigation is ongoing.
2. Deleted — the account can no longer be reanimated in its original active form, but records remain for auditing purposes; it is not necessarily inaccessible for audit/history review.
3. Removed — the account is no longer available at all; policy may dictate this happens only after a defined retention period (months or years).

Device-specific deprovisioning actions:

flowchart TD
    Start([Deprovisioning Trigger]) --> Reason{Reason}
    Reason -->|Good Terms| Voluntary[Standard Offboarding]
    Reason -->|Bad Terms| Involuntary[Legal Hold / Incident Handling]
    Reason -->|Internal Move| Transfer[Revoke Old Access<br/>Provision New Access]
    Reason -->|Device Lost/Stolen| DeviceLost[Lock -> Locate or Remote Wipe]
    Reason -->|Device EOL| DeviceEOL[Retire Device + Delete Account]

    Voluntary --> Disable[Disable / Hold]
    Involuntary --> Disable
    Disable --> Delete[Delete<br/>Reversible / Audited]
    Delete --> Removed[Removed<br/>After Retention Period]

The good news is that much of this can be automated using lifecycle workflows backed by cloud platform templates, typically aligned to compliance requirements. These workflows cover the full employee journey: joining, moving between departments, and leaving the organization.

Demo: Creating and Managing Accounts

This walkthrough continues in the Microsoft Entra ID portal, covering user accounts, device accounts, and automated lifecycle workflows.

Creating and managing a user account:

1. Navigate to Manage → Users to see the list of active users in the domain.
2. Select New user to either create a new user manually or invite an external user (a guest/collaborator from outside the organization).
3. On the Basics tab, mandatory properties include the user principal name, display name, and an auto-generated password (the user sets their own password on first logon). The account is enabled by default; unchecking this disables the account until the user actually joins — useful for pre-provisioning before a start date.
4. The Properties tab allows setting optional attributes — filling these in supports attribute-based access control (ABAC) and directory search.
5. The Assignments tab allows adding the user directly to groups or roles at creation time.
6. Review and create the user.

Managing an existing user account (example: “Alan”):

• The Overview pane shows the user principal name and group memberships.
• Account status can be toggled to disable the account (e.g., during offboarding or an extended leave of absence such as a sabbatical).
• From the top menu: edit properties, reset password, and revoke active sessions.
• Delete places the account into a 30-day recoverable state before it is permanently removed — allowing reinstatement if deletion was a mistake.

Managing device accounts:

1. Navigate to Devices in the Entra ID portal to view alerts and the full device inventory.
2. Selecting a device and choosing Manage opens device management actions, including:

Identity governance and automated lifecycle workflows:

• The Identity governance portal surfaces active users, configuration options, links back to Privileged Identity Management, and access reviews for auditing.
• Lifecycle workflows allow automation of onboarding, internal moves, and offboarding using preconfigured templates, such as:

Configuring the onboard new hire employee template involves:

1. Basics — trigger details and a name for the scheduled task.
2. Scope — rules determining which attributes/properties the workflow applies to.
3. Tasks — the ordered task list, for example: enable the user account → send a welcome email → add the user to relevant groups.

sequenceDiagram
    participant HR as HR System / Trigger
    participant LCW as Lifecycle Workflow Engine
    participant Entra as Entra ID
    participant User as New Hire

    HR->>LCW: New hire trigger (start date)
    LCW->>Entra: Enable user account
    LCW->>User: Send welcome email
    LCW->>Entra: Add user to relevant groups
    Entra-->>User: Account active with baseline access

flowchart LR
    subgraph Templates[Preconfigured Lifecycle Workflow Templates]
        T1[Onboard New Hire]
        T2[Group Membership Change]
        T3[Offboard & Leave]
    end
    Templates --> Config[Configure: Basics -> Scope -> Tasks]
    Config --> Run[Workflow Executes Automatically<br/>on Trigger]

Summary

This course established the foundational identity and access management concepts required to operate within a Zero Trust architecture:

• Identity is a set of claims about a subject (user, device, application, or organization), built from attributes such as name, role, biometrics, location, and possessions.
• IAAA (Identity, Authentication, Authorization, Accounting) is the core model underpinning access management, enforced through access control models such as DAC, MAC, RBAC, and ABAC.
• Zero Trust rests on three tenets — never trust, always verify, assume breach — with least privilege as a constant enforcement principle, and the CIA triad as the underlying data-protection goal.
• Legacy on-premises authentication (Active Directory/Kerberos) gave way to federated identity and now to cloud-native IAM (Entra ID, AWS, Google Cloud, Okta), built on open standards such as SAML, OpenID Connect, and OAuth 2.0 — all mapped conceptually to the NIST SP 800-207 Zero Trust reference architecture (subject → Policy Enforcement Point → Policy Decision Point → resource).
• Multi-factor authentication combines two or more of five factor categories (something you know/have/are, somewhere you are, something you do), with Microsoft Entra ID grouping these into MFA, passwordless MFA, and phishing-resistant MFA authentication strength tiers, enforced through conditional access policies based on user, device, location, and risk conditions.
• Least privilege for administrative accounts is enforced through JIT (time-bound activation) and JEA (minimum necessary scope), managed in practice through Privileged Identity Management (PIM).
• The IAM lifecycle — creation, management, and deprovisioning — governs accounts and devices from onboarding through offboarding, and can be substantially automated using lifecycle workflow templates for joiner/mover/leaver scenarios.

Quick-Reference: Zero Trust IAM Building Blocks

Zero Trust IAM Implementation Checklist

• Define identity attribute standards and classify PII handling requirements
• Map all subjects (users, devices, applications, organizations) requiring identities
• Enforce IAAA consistently across on-premises and cloud resources
• Choose and apply the appropriate access control model (DAC/MAC/RBAC/ABAC) per resource
• Adopt open federation standards (SAML/OIDC/OAuth 2.0) for cross-domain and external access
• Align architecture to NIST SP 800-207 (PEP/PDP model)
• Enforce MFA for all accounts; target passwordless or phishing-resistant tiers where possible
• Configure conditional access policies using risk, location, and device signals
• Maintain a custom banned-password list and strong lockout thresholds
• Implement least privilege for all administrative roles via JIT/JEA and PIM
• Audit privileged role activations through Discover & Monitor
• Define account and device deprovisioning policies for every departure/loss scenario
• Automate onboarding, internal moves, and offboarding with lifecycle workflows
• Regularly review access (access reviews) and log all account/role changes for auditing

Search Terms

zero · trust · identity · access · management · security · networking · systems · authentication · iam · account · accounts · mfa