Zero Trust Architecture: Foundational Concepts

This course explores Zero Trust architecture as the new standard for implementing robust security measures that protect against modern cyber threats by ensuring that no entity is trusted by default, whether it is inside or outside the network. It assesses the risks of perimeter-based security and implicit trust, explores the core Zero Trust principles and existing frameworks (with a strong focus on NIST SP 800-207), and covers how to implement Zero Trust using modern technologies and capabilities. Throughout the course, a fictitious company called Globomantics is used as a running scenario to put concepts into a realistic business context.

Table of Contents

• Module 1: Exploring the Need for Zero Trust
  • 1.1 Setting the Scene: Globomantics and Traditional Network Design
  • 1.2 Addressing Security Myths and Misconceptions
  • 1.3 Detecting the Insider Threat and Living-off-the-Land Attacks
  • 1.4 Security Risks with SaaS, Third Parties, and Managed Service Providers
  • 1.5 Module Recap: Why Perimeter-Only Security Fails
• Module 2: Defining Zero Trust Architecture
  • 2.1 What Is Zero Trust? Core Concept and Guiding Principles
  • 2.2 The Seven NIST Zero Trust Tenets (SP 800-207)
  • 2.3 The NIST Zero Trust Architecture Model
  • 2.4 Network Considerations Under Zero Trust
  • 2.5 The Building Blocks of Zero Trust: IAM, SSE, and SASE
  • 2.6 Challenges and Risks When Implementing Zero Trust
  • 2.7 Module Recap
• Module 3: Implementing Zero Trust
  • 3.1 From Principles to Practice
  • 3.2 Safeguarding Identity and Access Management
  • 3.3 Implementing Conditional Access
  • 3.4 Privileged Identity and Access Management
  • 3.5 Securing Access to Applications
  • 3.6 Continuous Monitoring and Reference Resources
• Summary

Module 1: Exploring the Need for Zero Trust

This module explores the risks that organizations face with traditional, perimeter-based security so that a strong business case can be built for Zero Trust initiatives. The fictitious company Globomantics is used throughout to put things into context: an organization that needs to improve its overall security posture. The module first covers the current technology landscape typical of an enterprise, then moves on to common security myths and misconceptions, the reality of insider threats, and the risks introduced by SaaS adoption and third-party/managed service provider (MSP) relationships.

1.1 Setting the Scene: Globomantics and Traditional Network Design

A computer network is the digital backbone of modern organizations, where employees use laptops, workstations, and mobile devices to consume services and applications hosted on servers connected to the same network. Collectively, these endpoints, servers, and application resources are referred to as compute.

Within a network, users rely on compute resources and the available infrastructure to access and process data. Applying the principle of perimeter-based security, everything within the network perimeter is granted implicit trust, whereas everything outside the network perimeter is not trusted. To communicate with the outside world, organizations historically deployed next-generation firewalls (NGFWs) that combine a router, firewall, intrusion detection, and content filtering into a single stack. This is where the perimeter-based security model was born: everything inside the perimeter is trusted, while all connections from outside require further verification.

Beyond the on-premises perimeter, the traditional design also has to account for:

• Remote employees, who connect through a VPN. After a successful authentication, these users are considered trusted and are granted access to resources — establishing a logical trust boundary that extends the perimeter to wherever the VPN client is used.
• Cloud services, hosting part of the infrastructure or services, typically reached via site-to-site VPN.
• Branch offices, connecting to the same set of resources using the same site-to-site VPN technologies.

flowchart TB
    subgraph Perimeter["Trusted Perimeter (Implicit Trust)"]
        Users["Internal Users / Workstations"]
        Servers["Internal Servers / Applications"]
        Users --> Servers
    end

    NGFW["Next-Generation Firewall<br/>Router + Firewall + IDS + Content Filtering"]
    Internet(["Public Internet<br/>(Untrusted)"])
    Remote["Remote Employee"]
    Cloud["Cloud-hosted Infrastructure"]
    Branch["Branch Office"]

    Internet -- "Requires verification" --> NGFW
    NGFW --> Perimeter
    Remote -- "VPN (authenticate once, then trusted)" --> Perimeter
    Cloud -- "Site-to-site VPN" --> Perimeter
    Branch -- "Site-to-site VPN" --> Perimeter

With this blueprint in mind — a trusted internal zone, a hardened perimeter, and VPN-extended trust for remote users, cloud, and branch offices — the module moves on to the risks this design creates.

1.2 Addressing Security Myths and Misconceptions

The most common and dangerous security myth is: “If it’s internal, it’s safe.” Publicly documented data breaches repeatedly disprove this assumption. The real issue is providing implicit trust — it is a risky assumption that threats only come from outside the network. This misconception has generated several major, well-documented categories of security risk:

1. Flat network design and lack of network segmentation.
2. Use of insecure protocols for internal applications.
3. Failure to remediate security vulnerabilities for internal applications with the same rigor applied to internet-facing systems.

Flat network design. A flat network lacks proper network segmentation. Some organizations start small, with a basic Internet → DMZ → trusted zone layout, but never continue to compartmentalize as the organization grows. In other cases, proper segmentation is skipped because of the additional operational overhead of managing access control lists (ACLs). The business impact materializes when a threat actor gains a foothold anywhere within the network perimeter: every host on that flat network then becomes exposed.

Insecure protocols at the application layer. Based on the false assumption that employees will never abuse security misconfigurations, some internal applications are not configured to use encrypted communication channels and instead rely on clear-text, insecure protocols such as HTTP or FTP. This creates two risk categories:

Even with a well-segmented, fully-encrypted network, threat actors still find other ways to infiltrate and pivot. Unpatched internal applications are a major example: internal-facing applications typically do not get the same patching priority as internet-facing ones. The risk grows over time as vulnerabilities and misconfigurations are ignored or overlooked — sometimes for months or years. Beyond stealing the information managed by these applications, threat actors can also abuse them as a pivot point for lateral movement.

flowchart LR
    Myth["Myth:<br/>'If it's internal, it's safe'"] --> Trust["Implicit trust granted<br/>inside the perimeter"]
    Trust --> Flat["Flat network /<br/>no segmentation"]
    Trust --> Insecure["Insecure protocols<br/>(HTTP, FTP, clear text)"]
    Trust --> Unpatched["Unpatched internal apps<br/>(lower patch priority)"]

    Flat --> Impact1["One foothold =<br/>every host exposed"]
    Insecure --> Impact2["Confidentiality loss:<br/>data + credential leakage"]
    Insecure --> Impact3["Integrity loss:<br/>man-in-the-middle tampering"]
    Unpatched --> Impact4["Data theft +<br/>lateral movement pivot"]

1.3 Detecting the Insider Threat and Living-off-the-Land Attacks

Protecting only at the perimeter level means that remote employees outside the perimeter remain unprotected. Consider a remote employee who visits a malicious website while not connected to the VPN: without content filtering or a web proxy in place, their computer can become infected. If that infected computer later connects to the internal network, it becomes an insider threat.

The insider threat is not limited to remote employees, however — threat actors can also use phishing emails over legitimate services and social engineering to target employees who are already inside the network. Once a user’s machine is infected, it takes advantage of implicit trust to connect back to the threat actor’s command-and-control (C2) infrastructure. At this point, the threat actor has gained a foothold and can begin executing their objectives inside the network.

Consider the scenario where the threat actor then identifies a vulnerable, internal-only application. Exploiting an unpatched vulnerability, or another misconfiguration such as clear-text communication, gives the threat actor access to sensitive data. From there, they can leverage lateral movement to expand control over other systems: with only perimeter-level defenses, the security team has no visibility into these east-west movements.

Modern threat actors increasingly avoid traditional exploits or bespoke malware. Instead they abuse legitimate IT administration tools — such as PowerShell or WMI on Windows — to facilitate post-exploitation. This class of technique is known as living off the land (LOTL). Signature-based perimeter detections such as traditional IDS/IPS cannot catch these techniques, because the traffic looks like ordinary, legitimate administrative activity once the actor has pivoted internally.

sequenceDiagram
    participant Remote as Remote Employee (no VPN)
    participant Mal as Malicious Website
    participant Internal as Internal Network
    participant C2 as Threat Actor C2
    participant App as Vulnerable Internal App
    participant Host2 as Other Internal Host

    Remote->>Mal: Browses without content filtering / web proxy
    Mal-->>Remote: Delivers malware, infects device
    Remote->>Internal: Connects infected device to internal network
    Internal->>C2: Implicit trust allows outbound C2 connection
    C2->>Internal: Threat actor gains a foothold
    Internal->>App: Exploits unpatched vulnerability / clear-text protocol
    App-->>Internal: Sensitive data disclosed
    Internal->>Host2: Lateral movement using PowerShell/WMI (living off the land)
    Note over Internal,Host2: Perimeter IDS/IPS has no visibility;<br/>traffic looks legitimate
    Internal->>C2: Data exfiltration

1.4 Security Risks with SaaS, Third Parties, and Managed Service Providers

Software as a Service (SaaS). Employees and services connect to SaaS applications reachable from the public internet, and organizational data is stored and processed inside the SaaS provider’s environment. This raises the question: how can perimeter defenses possibly protect data hosted in a SaaS application they do not control? SaaS adoption is popular because it removes hardware, patching, and infrastructure-management overhead — “technology without IT” — but because these solutions live on the public internet, SaaS is itself another argument against the perimeter security design pattern. Even where a SaaS application is well secured, organizations must still account for:

• Shadow IT — departments such as marketing, finance, or HR can purchase and adopt SaaS solutions without any IT design review or oversight.
• Data governance gaps — a lack of governance over data stored in SaaS can create regulatory/compliance problems.

Managed service providers (MSPs) and third parties. Organizations frequently outsource IT management and administration to MSPs, which requires delegating administrative privileges. Connectivity between an MSP and the organization is often facilitated through site-to-site VPN, and security assurance is typically achieved only through audits and certifications — but “security on paper” is often different from “security in practice.” In a flat network design, MSPs (and any external consultant granted VPN access) frequently get access to the entire network, including sensitive resources such as domain controllers.

The highest-impact risk here is the compromise of an MSP itself: even with an excellent internal security posture, a compromised MSP gives threat actors privileged access into the environment. Because MSPs achieve economies of scale by serving many clients with the same privileged access model, compromising a single MSP employee’s credentials can grant a threat actor access not just to Globomantics, but to every other client of that MSP as well. This is a simplified model — real attacks are typically more complex — but this exact pattern has occurred in real incidents, precisely because threat actors are incentivized to compromise one organization in order to gain access to all of its downstream clients.

flowchart TB
    subgraph SaaS_Risk["SaaS Risk"]
        Employees["Globomantics Employees"] -->|Corporate credentials| SaaSApp["SaaS Application<br/>(public internet)"]
        OtherDepts["Marketing / Finance / HR"] -->|"No IT oversight"| ShadowIT["Shadow IT"]
        SaaSApp -.->|"Perimeter defenses<br/>have no reach here"| DataStore["Customer Data<br/>(hosted by SaaS provider)"]
    end

    subgraph MSP_Risk["MSP / Third-Party Risk"]
        MSP["Managed Service Provider"] -- "Site-to-site VPN +<br/>privileged admin access" --> Globo["Globomantics Network"]
        MSP -- "Same privileged model" --> Client2["Other MSP Client A"]
        MSP -- "Same privileged model" --> Client3["Other MSP Client B"]
        Attacker["Threat Actor"] -->|"Compromises one<br/>MSP employee"| MSP
        MSP -->|"Blast radius"| Globo
        MSP -->|"Blast radius"| Client2
        MSP -->|"Blast radius"| Client3
    end

1.5 Module Recap: Why Perimeter-Only Security Fails

This module covered generic risks inherent to the traditional perimeter-based security model:

• Insider threat is largely ignored or under-considered.
• Lateral movement becomes possible once a threat actor gains any foothold, letting them expand within the network.
• Perimeter-only protections are inefficient at detecting modern post-exploitation techniques that rely on living off the land.
• SaaS adoption and outsourced administrative duties to multiple service providers make maintaining a secure, efficient perimeter impractical in modern organizations.

To mitigate modern threats, organizations need a new approach to safeguard against modern attacks — which is where Zero Trust comes in, covered starting in the next module.

Module 2: Defining Zero Trust Architecture

This module dives into the Zero Trust principle to understand why it has become the new baseline for network architecture, while maintaining a practical balance and avoiding overly theoretical treatment. It defines Zero Trust and Zero Trust architecture, covers the Zero Trust principles that set direction for security controls, introduces the technology-agnostic building blocks that enable a modern digital environment, and — because identity is the new perimeter — focuses on Identity and Access Management (IAM) as one of the integral Zero Trust solutions.

2.1 What Is Zero Trust? Core Concept and Guiding Principles

Zero Trust has become something of a buzzword, so many definitions exist. Kept simple: the main idea of Zero Trust is that we always verify before we provide trust. In contrast to perimeter-based security, the objective is to never provide implicit trust. Zero Trust focuses on protecting resources — assets, services, and workflows — not just network segments.

Zero Trust emerged out of necessity, as organizations needed to address the security concerns of the modern threat landscape: migrating to cloud environments, adopting SaaS solutions (for which establishing a perimeter is a challenge), and securing a remote workforce. Several important principles fall under the Zero Trust umbrella:

• Shift in focus from perimeter to identity. This does not mean decommissioning firewalls — it means that network location alone is not a definitive factor in establishing trust.
• Principle of least privilege. Administrators still need privileges to do their jobs, but should be granted only the minimal privileges required, so that if an account is compromised, the impact is much smaller than the compromise of a highly-privileged account.
• Assume breach. To address insider threat, organizations must acknowledge that security controls will eventually fail and security incidents will occur. What happens next matters: adopt an assume-breach mindset and continuously monitor the security posture of the environment, rather than deploying controls once and forgetting about them.

If Zero Trust is a compass pointing toward a better direction, Zero Trust architecture is the map: a security plan based on Zero Trust concepts, consisting of components, workflows, and access policies. Zero Trust is not a specific technology or product — it is a set of technologies and processes designed to prevent unauthorized access to data and services. Most organizations already have some of the necessary capabilities in place; they typically just need to configure or update them.

Balancing implicit trust and Zero Trust. Before removing everyone’s access, it’s important to maintain balance, usually driven by the organization’s risk appetite:

A good balance is often achieved by applying stricter Zero Trust controls to administrative accounts while implementing a more relaxed policy for regular accounts.

Reference frameworks. NIST provides a very detailed Zero Trust architecture framework, published as NIST SP 800-207, titled Zero Trust Architecture. This publication defines a set of seven Zero Trust tenets used as guiding principles — an ideal goal, acknowledging that not every tenet may be fully implemented in its purest form for any given strategy. A companion publication, NIST SP 800-207A, titled A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments, complements SP 800-207 with a focus on cloud-native architectures.

flowchart LR
    Perimeter["Perimeter-Based Security"] -->|"Trust = network location"| Implicit["Implicit Trust Inside Perimeter"]
    ZeroTrust["Zero Trust"] -->|"Trust = continuous verification"| Verify["Always Verify, Never Trust by Default"]

    Verify --> P1["Shift focus:<br/>perimeter → identity"]
    Verify --> P2["Least privilege"]
    Verify --> P3["Assume breach +<br/>continuous monitoring"]

2.2 The Seven NIST Zero Trust Tenets (SP 800-207)

The NIST Zero Trust tenets establish a set of principles against which security controls can be aligned:

mindmap
  root((NIST SP 800-207<br/>Seven Zero Trust Tenets))
    All resources
      Data + compute services
      On-prem and SaaS treated equally
    Secure communication
      Regardless of network location
    Per-session access
      No indefinite trust
      One user, one resource, one session
    Dynamic policy
      Identity + application + asset state
      Behavioral / environmental attributes
    Continuous monitoring
      Asset integrity and posture
    Strict authN/authZ enforcement
      Before access is allowed
    Telemetry collection
      Drives posture improvement

2.3 The NIST Zero Trust Architecture Model

One of the primary objectives of a Zero Trust architecture (ZTA) is to manage access to resources — systems, data, or applications. The NIST ZTA model introduces a set of logical components that stand between the subject and the resource:

• Policy Enforcement Point (PEP) — acts like a gatekeeper. It is conceptually similar to a firewall, except that a firewall manages connections to a network, whereas the PEP manages access to a resource. Based on successful authentication and authorization, the subject is granted access to the resource through a trusted session established by the PEP.
• Policy Decision Point (PDP) — the component that decides who and when to grant access. It is composed of two sub-components:
  • Policy Engine (PE) — responsible for the ultimate decision to grant access to a resource for a given subject, based on enterprise access policies as well as inputs from external sources (e.g. threat intelligence).
  • Policy Administrator (PA) — responsible for establishing and shutting down the communication path between the subject and the resource, by sending commands to the PEP.

The Zero Trust architecture’s logical components communicate over a separate control plane, while application data flows over the data plane. In an enterprise implementation, several data sources feed the Policy Engine’s decision-making, including local data sources and external data sources (e.g., threat intelligence feeds).

flowchart LR
    Subject["Subject<br/>(user / device / workload)"] -->|Access request| PEP["Policy Enforcement Point (PEP)<br/>Gatekeeper"]
    PEP <-->|Control plane| PA["Policy Administrator (PA)"]
    PA <--> PE["Policy Engine (PE)"]
    PE --> DataSources["Data Sources<br/>(local + external, e.g. threat intel)"]
    PEP -->|Data plane, trusted session| Resource["Resource<br/>(system / data / application)"]

    subgraph PDP["Policy Decision Point (PDP)"]
        PA
        PE
    end

2.4 Network Considerations Under Zero Trust

When implementing Zero Trust architecture, several network-level considerations follow directly from the core tenets:

• The enterprise network is not an implicit trust zone. The risks of implicit trust were already established in Module 1.
• Devices on the network may not be owned or managed by the enterprise — this includes computers/workstations owned and managed by external parties, as well as personal devices under bring-your-own-device (BYOD) policies.
• No resource is inherently trusted. Not all resources are hosted on enterprise infrastructure — SaaS applications are a good example.
• Enterprise-owned devices connected remotely cannot fully trust their local connection. For example, an employee working from a coffee shop, using a company computer to access enterprise resources, is on an untrusted local network.
• Security posture consistency must be maintained regardless of which infrastructure components an organization is migrating to or from.

2.5 The Building Blocks of Zero Trust: IAM, SSE, and SASE

With Zero Trust architecture principles and core concepts established, this section covers the important building blocks used to implement it.

Identity and Access Management (IAM). IAM is one of the most important building blocks, reflecting the shift away from traditional perimeter-based defenses. IAM solutions are the single source of truth for digital identities — used to store and manage identities for employees, external parties, and devices. IAM solutions manage requests from subjects to access enterprise resources through access policies. A core IAM component is the Identity Provider (IdP), which verifies user identities and provides information to other services; in NIST ZTA terms, the IdP typically functions as (or feeds) the policy enforcement and decision components.

Device identity matters too, and devices can be categorized by their level of control:

Based on conditional access, organizations can validate the state of security on a device before granting access — for example: Is the device fully patched? Is access protected by biometrics or a PIN? Is disk encryption enabled? These factors determine what level of access is granted.

Secure Service Edge (SSE) is not a single product but a set of capabilities used to implement Zero Trust, including:

• Secure Web Gateway (SWG) — provides secure web access for everyone regardless of network location, including URL filtering, application control, and threat detection.
• Firewall as a Service (FWaaS) — the cloud-delivered evolution of next-generation firewalls: access control, threat detection, and prevention for cloud environments.
• Zero Trust Network Access (ZTNA) — provides access to self-hosted applications based on identity and application policy (rather than network-level VPN access).
• Cloud Access Security Broker (CASB) — adds a layer of security when connecting to SaaS applications.

Secure Access Service Edge (SASE), pronounced “sassy,” is the next tier of security protection: it includes all SSE capabilities and adds a software-defined wide area network (SD-WAN) — a virtual WAN architecture that lets enterprises leverage any combination of transport services (including MPLS, LTE, and broadband internet) to securely connect users to applications.

There are many commercial SSE and SASE solutions available; it is up to each organization to evaluate them against the capabilities they need for their Zero Trust implementation.

flowchart TB
    IAM["Identity and Access Management (IAM)<br/>Single source of truth for identities"]
    IdP["Identity Provider (IdP)"]
    IAM --> IdP

    subgraph SSE["Secure Service Edge (SSE)"]
        SWG["Secure Web Gateway<br/>URL filtering, app control, threat detection"]
        FWaaS["Firewall as a Service<br/>Access control + threat prevention"]
        ZTNA["Zero Trust Network Access<br/>Identity + app-based access"]
        CASB["Cloud Access Security Broker<br/>SaaS security layer"]
    end

    SASE["Secure Access Service Edge (SASE)"]
    SDWAN["SD-WAN<br/>MPLS / LTE / broadband transport"]

    SSE --> SASE
    SDWAN --> SASE

2.6 Challenges and Risks When Implementing Zero Trust

Planning and implementing Zero Trust is not a walk in the park. Being informed about the challenges helps organizations prepare for them:

• Sheer complexity of implementation, driven by the deployment and integration of multiple security technologies and controls that must communicate and work together.
• Administration overhead, since continuous verification and managing access policies add operational load.
• Restricting and limiting access has trade-offs. Increasing authentication requirements can create friction for end users, so security requirements must be balanced against user productivity and convenience.
• Risk of over-engineering, particularly given implementation complexity and organizational size — making things more complex than they need to be.

No enterprise can eliminate cybersecurity risk completely, and the NIST Zero Trust architecture publication documents several specific threats to be aware of:

Despite these risks, they are generally considered to carry less impact than the risks created by providing implicit trust.

flowchart TB
    Challenges["Zero Trust Implementation Challenges"] --> C1["Complexity of<br/>integrating multiple controls"]
    Challenges --> C2["Administration overhead<br/>(continuous verification)"]
    Challenges --> C3["User friction vs<br/>productivity trade-off"]
    Challenges --> C4["Risk of over-engineering"]

    Risks["NIST-documented ZTA Threats"] --> R1["Subversion of<br/>ZTA decision process"]
    Risks --> R2["False positives from<br/>automated/API decisions"]
    Risks --> R3["Weak API-key auth"]
    Risks --> R4["Leaked ZTA<br/>design documentation"]
    Risks --> R5["Reduced visibility from<br/>encrypted C2 tunneling"]
    Risks --> R6["Stolen admin credentials"]
    Risks --> R7["Vendor lock-in"]
    Risks --> R8["DoS against<br/>Policy Administrator"]

2.7 Module Recap

This module covered the important principles of Zero Trust and how it overcomes the limitations of perimeter-based security by focusing on identity over implicit trust based on zones — for users, but also for devices and resources. Zero Trust is not a specific technology or service; it is a set of principles and a plan to improve resilience against modern threats given the current technology landscape.

Module 3: Implementing Zero Trust

Having covered Zero Trust principles and the risks they address, this module focuses on practical implementation. The cybersecurity landscape has evolved to the point where defining and maintaining protections solely based on the perimeter is impractical and inefficient — but this should be treated as a guiding principle, not a fixed destination. Each organization can decide what level of risk it is willing to accept and how much Zero Trust should impact usability and productivity.

3.1 From Principles to Practice

Two important misconceptions are worth addressing directly:

1. The perimeter is not dead. Organizations still rely on firewalls and network capabilities to segregate areas of the network — the difference is that the perimeter is no longer used solely as the deciding factor for trust.
2. There is no single Zero Trust product. The cybersecurity market is flooded with “Zero Trust solutions,” but no single solution facilitates Zero Trust for an entire organization. Instead, focus on a Zero Trust strategy that combines multiple capabilities working in tandem to improve security resiliency.

Because identity is more important than the perimeter, this module focuses on techniques and mechanisms for safeguarding Identity and Access Management, especially conditional access as the control plane for building rules and policies governing resource access. Because privileged access has an outsized impact when compromised, the module also covers privileged access and identity management, and finally explores how to reduce the attack surface to further mitigate the impact of breaches.

mindmap
  root((Implementing<br/>Zero Trust))
    Safeguarding IAM
      Identity provider
      SSO
      MFA
      CIAM
    Conditional access
      Signals
      Risk-based decisions
    Privileged access
      JIT / JEA
      PIM / PAM
      Tiering
      PAWs
    Reducing attack surface
      CASB
      Application proxy
      Microsegmentation

3.2 Safeguarding Identity and Access Management

At the core of every IAM solution is an Identity Provider (IdP) — essentially a database of users and devices, where “users” broadly includes employees, external consultants, service accounts, and other account types. The IdP’s second role is to facilitate authentication and authorization services for other applications. Active Directory is one of the most widely known such technologies, used in enterprise organizations for a very long time. In the modern era, hybrid IAM solutions link multiple identity providers together, satisfying requirements for both traditional on-premises protocols and modern cloud protocols.

Beyond employees, externals, and devices, there are also dedicated solutions for managing customer identities: Customer Identity and Access Management (CIAM).

Every IAM solution needs to provide a core set of security capabilities:

• Single sign-on (SSO) — after centralizing identities, users authenticate once and are authorized to access other resources without separate local accounts.
• Multi-factor authentication (MFA) — a strong authentication mechanism, especially important for public cloud and SaaS applications.
• Conditional access — the control plane enabling fine-grained access-control policies (covered in depth in the next section).
• User and device risk/profile evaluation — a robust IAM solution assesses risk continuously, not just at initial sign-in.

Single sign-on in depth. SSO is a mechanism to centrally manage identities and access. One goal is to limit the use of local accounts within individual applications: access is delegated by role to groups, and users are added to those groups. Employees use their corporate account via SSO instead of maintaining a separate local account per application. Benefits include:

• Usability — fewer passwords for users to remember.
• Compliance — better offboarding: when an employee leaves, there is less manual work required to disable and remove local accounts across every application.

SSO is particularly important for Zero Trust because it can be combined with a Cloud Access Security Broker (CASB) to manage access to SaaS applications — and because employees sign in with corporate credentials, this combination lets the organization detect shadow IT (i.e., when employees use their corporate account to sign up for services not sanctioned by IT).

Multi-factor authentication in depth. According to a Microsoft report released in 2020, MFA is one of the most effective account-protection mechanisms, reducing account-compromise risk by up to 99%. Because people use weak or reused passwords, credential stuffing attacks became widespread; MFA is an effective preventative measure because, even with a compromised password, the threat actor still needs the additional factor to gain access. This is why MFA has become a mandatory security requirement in modern enterprises — though a few important considerations apply:

• Some legacy or special account types may need to be exempt or handled separately: service accounts for on-premises solutions, shared mailboxes (if the corresponding account is not disabled), and workplace resources such as meeting-room accounts.
• Prefer stronger MFA mechanisms over weak ones. Avoid vulnerable mechanisms such as SMS or phone calls; instead, leverage time-based one-time passwords (TOTP).
• For administrators, use even stronger mechanisms such as passkeys, certificates, or biometrics.
• Assess whether legacy protocols such as SMTP are disabled, since these can be used to circumvent MFA entirely.

flowchart LR
    User["User"] -->|"Corporate credentials"| IdP["Identity Provider (IdP)"]
    IdP -->|"SSO"| App1["Application A"]
    IdP -->|"SSO"| App2["Application B"]
    IdP -->|"SSO"| SaaSApp["SaaS Application via CASB"]
    IdP -->|"MFA challenge"| MFA["Multi-Factor Authentication"]
    MFA -->|"TOTP / passkey / certificate / biometric"| IdP

    CASB["CASB"] -.->|"Detects shadow IT"| SaaSApp

3.3 Implementing Conditional Access

For a Zero Trust approach to authentication, multiple signals feed the access decision beyond just the password: user location, device type, application, and communication protocol. Based on these signals, the resulting decision can range from simply granting access, to requiring MFA, to limiting access (for example, a user may be allowed to view a document but not download it), to forcing a password reset based on assessed user risk. The IAM solution should continuously monitor requests to resources and conditional access decisions, with the goal of securely granting the access the user originally sought.

User and sign-in risk is a critical component for protecting identities against theft and impersonation. Modern IAM solutions collect a large amount of signal during authentication — IP location, device type, connection protocol — enabling more advanced conditional access policies:

• Force MFA when suspicious activity is detected, such as unusual sign-in properties.
• Detect impossible travel — sign-ins performed in a short time span from different, geographically distant locations (e.g., different countries).
• Mitigate account compromise by forcing a password change (performed securely, via MFA) when a compromised password is detected.

Device-based conditional access. In line with Zero Trust principles, it is recommended to restrict access to resources based on the device being used:

• Depending on environment/capability, allow files and documents to be viewed online only, without local download, to improve data-loss prevention (DLP).
• Enforce the use of Privileged Access Workstations (PAWs) for administrative tasks, and restrict access to admin portals from regular devices — reducing both the attack surface and the impact of incidents.
• Design and implement a secure way of working for administrative tasks performed by service providers/MSPs (echoing the risk highlighted in Module 1).

sequenceDiagram
    participant U as User
    participant CA as Conditional Access Engine
    participant Signals as Signals (location, device, app, protocol)
    participant Policy as Access Policy

    U->>CA: Sign-in attempt (password)
    CA->>Signals: Collect IP location, device posture, protocol
    Signals-->>CA: Risk signals (e.g. impossible travel, unmanaged device)
    CA->>Policy: Evaluate policy against signals
    alt Low risk, trusted device
        Policy-->>U: Grant access
    else Elevated risk
        Policy-->>U: Require MFA
    else High risk / unmanaged device
        Policy-->>U: Limit access (view only) or force password reset
    end

3.4 Privileged Identity and Access Management

Because escalating privileges is a goal of nearly every cyberattack, the principle of least privilege becomes a key guiding factor for post-exploitation risk reduction: avoid overly permissive accounts. Two capabilities make this manageable in practice:

• Just-in-Time (JIT) access — administrative privileges are assigned only for the period of time they are actually needed.
• Just-Enough-Administration / Just-Enough-Access (JEA) — assign the lowest amount of administrative privilege required. If only user administration is required, do not assign global administrator privileges.

Azure Privileged Identity Management (PIM) is a Microsoft-specific capability that implements these ideas. It is built into Microsoft Entra ID, works with Entra ID administrative roles as well as Azure subscription roles. When a user becomes eligible for a specific admin role, they must manually request activation of the entitlement, which is granted only temporarily (a few hours, by default). PIM can also enforce an approval process, requiring another person to sign off before privileges are elevated, adding an additional layer of control. Even where PIM itself is vendor-specific, its capabilities should be used as requirements when evaluating other privileged-access solutions.

Privileged Access Management (PAM) solutions act as a proxy for privileged accounts:

• Passwords can be rotated automatically after use.
• A full audit trail is created of who had privileged access, when, and to which system.
• Credentials are stored in a vault, and the process is transparent to the privileged user.
• PAM solutions integrate with a wide range of applications, similarly to PIM, with the shared goal of securing privileged access.

Administrative account tiering. Beyond least privilege, tiering admin accounts has become standard practice in modern enterprises:

The goal is to keep admin accounts separate per tier so that, if one admin account is compromised, the blast radius is isolated to a single tier. Logons between tiers are forbidden to prevent privilege escalation — for example, a Tier 2 account can never be used for administrative tasks on servers or a domain controller, and a Tier 1 account can never log on to a domain controller.

Privileged Access Workstations (PAWs). These accounts are used from dedicated devices reserved for highly sensitive roles and tasks — roles that, if compromised, could have a significant or material impact on the organization. PAWs enforce security policies to minimize the attack surface:

• Used only for administrative tasks — never for reading email or browsing the web, mitigating phishing/social-engineering risk.
• Application control enabled — no applications installed other than those required for administration.
• Microsoft defines a PAW as a hardened workstation with clear application control and Application Guard, using Credential Guard, Device Guard, App Guard, and Exploit Guard to protect the host from malicious behavior.
• All local disks are encrypted with BitLocker.
• Web traffic is restricted to a limited set of permitted destinations; all other destinations are denied.

flowchart TB
    subgraph Tiering["Administrative Account Tiering"]
        T0["Tier 0<br/>Domain controllers, identity, PKI"]
        T1["Tier 1<br/>Servers, enterprise apps, cloud services"]
        T2["Tier 2<br/>Workstations and endpoints"]
        T2 -. "Forbidden logon" .-x T1
        T1 -. "Forbidden logon" .-x T0
        T2 -. "Forbidden logon" .-x T0
    end

    Admin["Administrator"] -->|"Request eligible role"| PIM["Azure PIM<br/>(JIT activation + approval)"]
    PIM -->|"Temporary elevation<br/>(a few hours)"| T0
    Admin -->|"Uses"| PAW["Privileged Access Workstation<br/>(Credential/Device/App/Exploit Guard, BitLocker)"]
    PAW --> T0
    PAW --> T1

    PAM["PAM Solution<br/>(vault + rotation + audit trail)"] --> T0
    PAM --> T1

3.5 Securing Access to Applications

Applications are the primary way users process data, so the final building blocks in this module focus on securing access to them.

Protecting SaaS applications. Traditional solutions such as VPNs or IP allow-listing are not scalable or easy to manage in a modern digital workplace, and some SaaS providers may not even support this type of connectivity. Cloud Access Security Broker (CASB) is the modern solution — tightly integrated with (or part of) the IAM solution, it manages access to SaaS solutions through fine-grained access policies, and, as previously discussed, is also a good detection mechanism for shadow IT.

Securing remote access to internal applications. Traditional VPN and site-to-site VPN solutions provide access to the network rather than to specific applications — a high risk in flat network designs, where gaining VPN access effectively means gaining access to the whole network. Application proxy is the modern alternative: it grants access to specific on-premises applications with far more granularity than a traditional VPN, at the application layer rather than the network layer.

In a typical application proxy scenario, a remote user needs secure access to an on-premises application without a VPN:

1. A proxy connector is installed in the same environment as the application.
2. The connector connects outbound to a proxy service / gateway.
3. Users connect to that gateway service, through which they reach the on-premises application — with no inbound VPN connection required.

sequenceDiagram
    participant U as Remote User
    participant GW as Proxy Service / Gateway
    participant Conn as Proxy Connector
    participant App as On-Premises Application

    Conn->>GW: Outbound connection registration (no inbound firewall rule needed)
    U->>GW: Request access to application (identity + policy checked)
    GW->>Conn: Forward request over established outbound channel
    Conn->>App: Relay request
    App-->>Conn: Response
    Conn-->>GW: Relay response
    GW-->>U: Deliver application response
    Note over U,App: No VPN connection to the network is ever established

Microsegmentation. Consider a generic enterprise environment: a DMZ zone hosting web applications, a guest segment mainly for personal devices/visitors with only internet access, and the internal zone hosting servers and databases. The risk arises when one application is compromised: without segmentation, a threat actor can use it as a pivot to perform lateral movement and compromise other applications, exactly the flat-network risk discussed in Module 1.

With microsegmentation, applications are isolated so that they can only connect to — and receive connections from — the specific services they are explicitly allowed to communicate with. A compromised vulnerable application is then contained within its own segment. This applies especially well to modern application architectures such as microservices and containers, where segmentation can be applied at the individual workload level, providing much stronger resilience against lateral-movement attacks.

flowchart TB
    subgraph Before["Without Microsegmentation"]
        DMZ1["DMZ: Web App"] --- Guest1["Guest Segment"]
        DMZ1 --- Internal1["Internal Zone: Servers / DBs"]
        Compromised1["Compromised App"] -->|"Lateral movement<br/>(flat network)"| Internal1
    end

    subgraph After["With Microsegmentation"]
        DMZ2["DMZ: Web App"]
        Guest2["Guest Segment"]
        Workload1["Workload A"]
        Workload2["Workload B"]
        Workload3["Workload C (compromised)"]
        Workload3 -.->|"Blocked:<br/>not explicitly allowed"| Workload1
        Workload3 -.->|"Blocked"| Workload2
    end

3.6 Continuous Monitoring and Reference Resources

One of the last important pieces of Zero Trust rests on the assume-breach principle and continuous monitoring of the organization’s security posture, addressing and mitigating insider-threat risk. A key modern detection capability is User and Entity Behavioral Analytics (UEBA), which complements signature- and policy-based detection using heuristics and artificial intelligence — alongside Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) to gain visibility across the entire environment. These capabilities have become standard tools for detecting and mitigating modern cyberattacks.

Useful reference resources for driving Identity and Access Management and cloud-provider requirements (indispensable if using Microsoft or AWS, and still valuable as a reference otherwise):

• Conditional access documentation/reference.
• The enterprise access model, including guidance on admin account tiering.
• The Azure Architecture Center.
• The AWS Well-Architected portal — both provide strong reference material on secure-by-design principles for modern applications.

flowchart LR
    Breach["Assume Breach"] --> Monitor["Continuous Monitoring"]
    Monitor --> UEBA["User and Entity<br/>Behavioral Analytics"]
    Monitor --> EDR["EDR"]
    Monitor --> XDR["XDR"]
    UEBA --> Insight["Environment-wide<br/>detection & response"]
    EDR --> Insight
    XDR --> Insight

Illustrative example — Conditional access policy (representative structure only, not sourced from a specific vendor product):

{
  "policyName": "Require-MFA-for-Admins-and-Risky-Signins",
  "conditions": {
    "users": {
      "include": ["AdminRole-Tier0", "AdminRole-Tier1"]
    },
    "applications": {
      "include": ["All cloud apps"]
    },
    "signInRisk": ["medium", "high"],
    "locations": {
      "exclude": ["Trusted corporate network"]
    },
    "devicePlatform": ["Windows", "macOS", "iOS", "Android"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa", "compliantDevice"]
  },
  "sessionControls": {
    "signInFrequency": "4 hours",
    "blockDownloads": true
  }
}

Illustrative example — Just-in-time privileged role activation request (representative structure only):

{
  "requestedRole": "Tier0-Global-Administrator",
  "justification": "Emergency identity infrastructure maintenance",
  "duration": "PT4H",
  "requiresApproval": true,
  "approvers": ["security-lead@globomantics.example"],
  "mfaVerifiedAt": "2026-07-01T14:32:00Z"
}

Summary

Zero Trust architecture reframes security around one core idea: always verify, never trust by default — regardless of whether a user, device, or workload is inside or outside the traditional network perimeter. The foundational concepts covered in this course can be synthesized as follows:

• Perimeter-based security fails in modern environments because it grants implicit trust to everything “inside,” ignores the insider threat, cannot stop lateral movement or living-off-the-land techniques, and cannot meaningfully protect SaaS applications or account for the risks introduced by MSPs and third parties.
• Zero Trust is a set of principles, not a product — codified by NIST in SP 800-207 (and extended for cloud-native/multi-cloud environments by SP 800-207A) through seven guiding tenets and a reference architecture built around the Policy Enforcement Point, Policy Engine, and Policy Administrator.
• Identity is the new perimeter. IAM, SSO, MFA, and conditional access form the control plane that decides, per session and based on dynamic signals, whether access should be granted, challenged, limited, or denied.
• Privileged access deserves special protections — least privilege, JIT/JEA, PIM, PAM, account tiering, and Privileged Access Workstations all work together to minimize the blast radius of a compromised administrative account.
• Reducing the application attack surface — through CASB, application proxy, and microsegmentation — replaces network-wide VPN trust with fine-grained, identity-driven access to specific applications and workloads.
• Zero Trust must be balanced against usability, typically by applying the strictest controls to privileged/administrative accounts while keeping regular-user experience productive, and it must be paired with continuous monitoring (UEBA, EDR/XDR) under an assume-breach mindset, since no architecture eliminates risk completely.

Quick Reference: Perimeter-Based Security vs. Zero Trust

Zero Trust Implementation Checklist

• Map current network design, trust zones, and VPN-based trust extensions.
• Identify flat network segments and insecure (clear-text) internal protocols.
• Inventory SaaS applications in use, including shadow IT, and assess governance gaps.
• Review MSP/third-party access models and minimize standing, broad-scope VPN access.
• Adopt the NIST SP 800-207 tenets as guiding principles for policy design.
• Deploy or consolidate an Identity Provider as the IAM system of record; add CIAM if customer identities are in scope.
• Enforce SSO everywhere feasible to reduce local accounts and improve offboarding.
• Require MFA for all accounts, using TOTP or stronger (passkeys/certificates/biometrics) for administrators; eliminate legacy protocols that bypass MFA.
• Implement conditional access using signals such as location, device compliance, application, and sign-in risk.
• Apply least privilege, JIT/JEA, and administrative account tiering (Tier 0/1/2) with forbidden cross-tier logons.
• Deploy Privileged Access Workstations for all sensitive administrative roles.
• Replace VPN-based application access with application proxy / ZTNA where possible.
• Apply microsegmentation to critical workloads, microservices, and containers.
• Establish continuous monitoring via UEBA, EDR, and XDR under an assume-breach mindset.
• Secure and restrict access to Zero Trust architecture documentation and policy configuration.
• Periodically reassess the balance between security controls and user productivity.

Search Terms

zero · trust · architecture · foundational · concepts · security · networking · systems · access · identity · management · network · nist · principles · reference · risks