Episode 26 · Module 6 · Authorization & Access Control

Zero Trust Architecture

19 May 2026 · 8:33 · Security for Legal SaaS

8:33 8:33

For decades, network security operated on a simple assumption: everything inside the corporate network is trusted, everything outside is not. The firewall was the castle wall. If you were inside — physically in the office or connected to the VPN — you could access internal resources freely. That model is dead. Remote work, cloud services, and SaaS applications mean that the "inside" and "outside" distinction no longer exists. A partner working from a hotel in Singapore accesses the same case management system as an associate in the New York office. A legal SaaS platform runs on AWS, not in a server room. The data flows across the public internet.

Today’s Lesson

Security for Legal SaaS — Episode 26: Zero Trust Architecture

The Death of the Network Perimeter

That model is dead. Remote work, cloud services, and SaaS applications mean that the "inside" and "outside" distinction no longer exists. A partner working from a hotel in Singapore accesses the same case management system as an associate in the New York office. A legal SaaS platform runs on AWS, not in a server room. The data flows across the public internet. The perimeter is everywhere — which means it's nowhere.

Zero Trust is the security model built for this reality. It was first articulated by John Kindervag at Forrester Research in 2010, formalised by NIST in SP 800-207 (2020), and adopted as US federal policy under Executive Order 14028.¹

The Three Principles

Zero Trust rests on three principles:

Principle	What It Means	Legal SaaS Example
Never trust, always verify	No entity is trusted by default — not users, not devices, not networks	A lawyer on the office VPN still authenticates and authorises for every request
Assume breach	Design systems as if an attacker is already inside your network	If the database server is compromised, lateral movement to the document store is still blocked
Least-privilege access	Every entity gets the minimum permissions needed, for the minimum time needed	An associate gets read access to their assigned matters — not all matters, not forever

These principles extend the defence-in-depth concept we covered in Episode 4. Defence in depth layers multiple security controls. Zero Trust makes each layer verify independently — no layer assumes a previous layer already checked.

NIST SP 800-207: The Architecture

NIST SP 800-207 defines three core components of a Zero Trust Architecture:¹

Component	Role	Implementation
Policy Engine (PE)	Makes access decisions based on policies, identity, device state, and context	Could be a policy engine like OPA or Cedar (from Episode 24)
Policy Administrator (PA)	Translates the PE's decisions into action — issues session tokens, configures access paths	Often part of your identity layer or API gateway
Policy Enforcement Point (PEP)	Applies decisions at the resource boundary — allows or blocks the actual request	API middleware, network gateway, or service mesh proxy

The flow for every access request:

User/device sends a request to the PEP
PEP forwards identity and context to the PE
PE evaluates policies using attributes (identity, device, location, time, risk score)
PE returns allow/deny to the PA
PA instructs the PEP to permit or block the request
If permitted, the session is established with minimum required privileges

Key insight: This happens on every request, not just at login. A traditional system authenticates once and grants a session. Zero Trust re-evaluates continuously — the user's device compliance could change, their risk score could escalate, or an anomaly could be detected mid-session.²

Identity-Based Access

In Zero Trust, identity is the new perimeter. Every request carries proof of identity and authorisation — not just a session cookie created at login, but continuously verified credentials. This connects directly to the authentication and authorisation stack we've built across Episodes 17-25:

Authentication (Episodes 17-22): Passwords, MFA, SSO, SAML — proving who the user is
Authorisation (Episodes 23-25): RBAC, ABAC, ethical walls — deciding what they can do
Continuous verification: Re-evaluating both on every request, not just at session start

For legal SaaS, this means the JWT token or session (from Episode 18) should carry not just identity but context — device compliance status, network location, authentication strength — and the authorisation layer should evaluate all of it on every API call.³

Microsegmentation

Microsegmentation divides your infrastructure into fine-grained zones, each with its own access controls. In a traditional network, once you're past the firewall, you can reach everything. With microsegmentation, each service, database, and API has its own boundary.⁴

For a legal SaaS platform:

Segment	Contains	Access Rules
Document service	Document storage, version control	Only the API gateway and authorised microservices can reach it
Billing service	Financial data, invoicing	Only billing API endpoints, restricted to admin and partner roles
Search service	Full-text index, matter metadata	Only the search API, filtered by ethical walls (Episode 25)
Database	PostgreSQL/MySQL instance	Only application services on specific ports — never directly accessible from the internet
User service	Authentication, session management	Only the API gateway and identity provider

The CISA Zero Trust Maturity Model explicitly identifies microsegmentation as a foundational control: "not a nice-to-have or an advanced-stage optimization" but essential infrastructure.⁵

If an attacker compromises the document service, microsegmentation prevents them from pivoting to the billing database or the user authentication service. Each hop requires a separate authorised connection. This is the practical meaning of "assume breach" — you design each segment to survive even if adjacent segments are compromised.

The CISA Zero Trust Maturity Model

The CISA Zero Trust Maturity Model provides a roadmap with four maturity stages across five pillars:⁵

Pillar	Traditional	Initial	Advanced	Optimal
Identity	Password-only, static groups	MFA, basic SSO	Phishing-resistant MFA, continuous validation	Identity-driven, risk-adaptive access
Devices	No inventory	Basic inventory	Device compliance checked at access time	Real-time device health integrated into every decision
Networks	Flat network, perimeter firewall	Basic segmentation	Microsegmentation, encrypted east-west traffic	Fully encrypted, software-defined perimeters
Applications	Monolithic, trusted internally	Some API gateway controls	Per-service authorisation	Every service independently verified
Data	Unclassified, broadly accessible	Basic classification	Encryption + access controls by classification	Automated classification, real-time protection

Most legal SaaS platforms should target "Advanced" across all pillars. "Optimal" is aspirational for most organisations but increasingly expected for platforms handling national security or government legal work.

Practical Zero Trust for a Small Team

Zero Trust sounds like a massive infrastructure project. For a small legal SaaS team, here's a prioritised implementation path:⁶

Phase 1: Identity Foundation (Weeks 1-4)

Enforce MFA for all users (Episode 21)
Implement SSO with SAML/OIDC (Episode 22)
Short-lived sessions with automatic token refresh (Episode 19)

Phase 2: API-Level Enforcement (Weeks 5-8)

Every API endpoint checks authorisation — no implicit trust (Episode 23)
Deploy a policy engine for ABAC decisions (Episode 24)
Log all access decisions with immutable audit trails

Phase 3: Network Segmentation (Weeks 9-12)

Database never directly accessible from the internet
Service-to-service authentication (mTLS, from Episode 15)
Separate network segments for different service tiers

Phase 4: Continuous Verification (Ongoing)

Device compliance checking at access time
Anomaly detection — unusual access patterns trigger step-up authentication (Episode 19)
Risk-adaptive policies that tighten access when risk indicators increase

The 80/20 rule: Phases 1 and 2 deliver most of the security benefit. If you do nothing else, enforce MFA, implement SSO, and check authorisation on every API request. That alone moves you from a perimeter-based model to an identity-based one.⁶

Google BeyondCorp: The Original Implementation

Google's BeyondCorp initiative, published in a series of papers from 2014 onwards, was the first large-scale production implementation of Zero Trust.⁷ Google eliminated the corporate VPN entirely — internal applications are accessed the same way from the office as from a coffee shop. Every request is authenticated, every device is verified, and access decisions are made per-request based on identity and device state.

BeyondCorp proved that Zero Trust is not just theoretical. It works at the scale of one of the world's largest technology companies. For legal SaaS platforms, the lesson is clear: if Google can eliminate implicit trust for 100,000+ employees, a 50-person SaaS company can certainly adopt the same principles.

What's Next

Episode 27 covers Multi-Tenant Data Isolation — how your SaaS platform keeps 50 different law firms' data completely separate, and what happens when the isolation fails.

Sources & Further Reading

Sources & references

NIST, SP 800-207: Zero Trust Architecture — the foundational zero trust standard.
NIST, SP 800-207A: Zero Trust Architecture Model for Access Control in Cloud-Native Applications — cloud-native ZTA guidance.
Palo Alto Networks, What is NIST SP 800-207? — overview of the NIST ZTA framework.
CISA, Microsegmentation in Zero Trust — CISA guidance on microsegmentation as a foundational ZTA control.
CISA, Zero Trust Maturity Model — five-pillar maturity framework.
TerraZone, NIST SP 800-207: Complete Guide to Zero Trust Architecture (2025) — practical implementation guide.
Google Cloud, BeyondCorp — Google's zero trust implementation.
CyberArk, What is NIST SP 800-207? — ZTA framework overview.
Zero Networks, CISA Guidance Confirms: Microsegmentation Is Foundational for Zero Trust — analysis of CISA microsegmentation guidance.
Seraphic Security, Top 4 Zero Trust Frameworks in 2026 — framework comparison and selection guide.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 26 — Zero Trust Architecture. Alice, we first mentioned zero trust way back in Episode 4 when we talked about defence in depth. Now we're doing the deep dive. What's the core idea?

Alice: The core idea is that your network location means nothing. Traditionally, security worked like a castle. There's a firewall — the castle wall — and everything inside is trusted. If you're on the corporate network or connected to the VPN, you can access internal systems freely. Zero trust says that model is broken. A partner working from a hotel room in Singapore, an associate at the New York office, and a contractor on their personal laptop are all treated the same way. None of them are trusted by default. Every single request has to prove its right to exist.

Dan: Right. So "never trust, always verify" — that's the phrase I keep hearing.

Alice: That's one of the three principles. Never trust, always verify — no entity is trusted by default, regardless of where they are. Assume breach — design your systems as if an attacker is already inside your network. And least-privilege access — everyone gets the minimum permissions they need, for the minimum time they need them. We've been building toward this all series. MFA in Episode 21, SSO in Episode 22, RBAC in 23, ABAC in 24. Zero Trust is the architecture that ties all of those together.

Dan: Mm. NIST has a standard for this, right?

Alice: NIST SP 800-207, published in 2020. It defines three components. The Policy Engine makes access decisions — it evaluates who you are, what device you're on, what you're trying to access, and what the risk looks like. The Policy Administrator translates those decisions into action — it issues tokens or configures access. And the Policy Enforcement Point is the actual gate — it allows or blocks the request at the resource boundary. Think of the Policy Engine as the judge, the Administrator as the clerk, and the Enforcement Point as the door.

Dan: Mm-hmm. And this happens on every request? Not just at login?

Alice: On every request. That's the fundamental difference from traditional security. A traditional system authenticates you once, gives you a session cookie, and trusts that cookie for the next eight hours. Zero trust re-evaluates continuously. Your device compliance could change — maybe your antivirus went out of date. Your risk score could escalate — maybe you're suddenly accessing resources you've never touched before. An anomaly could be detected mid-session. The system adapts in real time.

Dan: Hmm. That sounds like a massive infrastructure project. What does a small team actually implement first?

Alice: There's an 80/20 rule here. Two things give you most of the security benefit. First, enforce MFA for every user and implement SSO — we covered both in the last few episodes. Second, check authorisation on every API request — not just at login, but on every call. That middleware pattern from Episode 23, where every endpoint checks the user's permissions before executing. Those two things together move you from a perimeter-based model to an identity-based one. You don't need to rearchitect your entire network overnight.

Dan: Right. What comes after that?

Alice: Microsegmentation. Instead of one flat network where every service can talk to every other service, you divide your infrastructure into isolated zones. Your document storage service is in one segment. Your billing service is in another. Your database is in a third. Each segment has its own access controls. The document service can talk to the database, but only on specific ports with authenticated connections. The billing service cannot reach the document store directly. If an attacker compromises one service, microsegmentation stops them from pivoting to everything else.

Dan: Mm. That's the "assume breach" principle in practice.

Alice: Exactly. You're not trying to prevent every breach — that's impossible. You're containing the blast radius. If the document service is compromised, the billing database is still safe because it's in a separate segment with its own authentication. CISA — the US Cybersecurity and Infrastructure Security Agency — recently published guidance calling microsegmentation "foundational" for zero trust. Not advanced. Not optional. Foundational.

Dan: Yeah. For a legal SaaS platform specifically, what does this look like?

Alice: Your database should never be directly accessible from the internet. Only your application services, on specific ports, with authenticated connections. Your search service — which has the full-text index we talked about in Episode 25, including the ethical wall filters — is a separate segment. Your user authentication service is isolated. And the communication between all of these uses mTLS — mutual TLS, which we covered in Episode 15 — so each service proves its identity to every other service it talks to.

Dan: Mm-hmm. Let me ask about the CISA maturity model. Where should a legal SaaS platform aim?

Alice: <sigh> Ideally, "Advanced" across all five pillars — identity, devices, networks, applications, and data. But let me be realistic. Most small SaaS teams start at "Traditional" — passwords, flat networks, monolithic applications. Getting to "Initial" — MFA, basic SSO, some API gateway controls — is achievable in weeks. Getting to "Advanced" — phishing-resistant MFA, microsegmentation, per-service authorisation, encrypted internal traffic — takes months. "Optimal" — fully risk-adaptive, real-time device health in every decision — is aspirational for most and takes years.

Dan: Right. But the first steps are high-value, low-effort.

Alice: Yes. And here's the business case. Enterprise law firm clients are increasingly asking about zero trust in security questionnaires. "Do you enforce least-privilege access?" "Are your internal services authenticated?" "Do you segment your network?" If you can say yes with evidence — access logs, architecture diagrams, policy engine configurations — you pass the assessment. If you're still on the castle-and-moat model, that's a red flag.

Dan: Mm. The Google BeyondCorp example always comes up in these discussions. How relevant is that for a smaller company?

Alice: BeyondCorp proved the model works at extreme scale — Google eliminated VPNs entirely. Internal applications are accessed the same way from the office as from a coffee shop. Every request is authenticated and authorised based on identity and device state. For a 50-person legal SaaS company, the lesson is: if Google can do this for 100,000 employees, you can adopt the same principles. You don't need Google's infrastructure. You need the mindset — stop trusting the network, start verifying every request.

Dan: Right. Quick practical summary for builders — enforce MFA and SSO, check authorisation on every API call, segment your network so services can't freely talk to each other, and use mTLS for service-to-service communication.

Alice: And log everything. Zero trust without audit trails is just aspirational security. The logs prove the verification is happening.

Dan: Next episode — Multi-Tenant Data Isolation. How your SaaS keeps 50 different law firms' data completely separate.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.