[Security Architecture] Zero Trust - Trust Nothing, Always Verify

About this article

As the sixth installment of the “Security Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains zero trust.

The security philosophy of “Never Trust, Always Verify” - with Google BeyondCorp as the prototype. This article covers the 5 zero-trust principles, the components of ZTNA/SASE/microsegmentation/continuous monitoring, a phased introduction roadmap, and the AI-era new common sense of treating humans and AI agents as equals.

What is zero trust in the first place

Think of airport security. Every passenger — even airline employees — goes through baggage inspection, passport verification, and identity check at the boarding gate. There is no “they’re staff, so face-pass is OK” system.

Zero trust applies the same idea. Rather than unconditionally trusting someone because they’re on the internal network, it’s a security model that verifies every access every time. Who is the user, is the device safe, is the location legitimate, is the time of day unusual — these contextual signals are comprehensively evaluated to allow or deny access each time.

Without zero trust, an attacker who breaches the internal network once can freely move anywhere. In practice, many large-scale data breaches started from a small entry point but expanded through lateral movement inside.

Castles and moats can no longer fight

Traditional “perimeter-based” security was built on the premise that “the corporate LAN is safe, inside the VPN is trusted.” But with cloud, SaaS, and remote work blurring boundaries, the assumption that “the inside is safe” no longer holds.

Zero trust is a philosophy, not a product name. Adoption isn’t a finish - it’s a company-wide design change.

Why it’s needed

1. The perimeter has disappeared

Employees remote, data on SaaS, servers on cloud - the concept of “inside the company” no longer exists. The boundary line to defend can’t be drawn physically.

2. Insider threats and lateral attacks

If attackers breach one PC, they can move laterally in the corporate LAN. Designing not to trust the inside is essential to prevent damage expansion after perimeter breach.

3. The reality of cloud/SaaS era

Salesforce, Slack, GitHub, AWS - everything is external. All communication routes “outside,” so perimeter defense doesn’t function.

The 5 zero-trust principles

Basic principles of the zero-trust architecture defined in NIST SP 800-207. Stick to these and you automatically become zero trust - the guideline.

flowchart LR
    subgraph OLD["Perimeter-based (legacy)"]
        WALL[Firewall]
        IN[Inside trusted]
        WALL -.|authenticated once at gate| IN
    end
    subgraph ZT["Zero Trust"]
        REQ([All requests]) --> POL[Policy Engine]
        POL --> CTX[Context evaluation<br/>ID/device/location/time]
        CTX -->|allow| RES[Resource]
        CTX -->|deny| DENY[Access denied]
    end
    classDef old fill:#fee2e2,stroke:#dc2626;
    classDef new fill:#dcfce7,stroke:#16a34a;
    classDef policy fill:#dbeafe,stroke:#2563eb;
    classDef deny fill:#fef3c7,stroke:#d97706;
    class OLD,WALL,IN old;
    class ZT,REQ,RES new;
    class POL,CTX policy;
    class DENY deny;

Principle	Content
Treat all resources as protected	Data, devices, users - all
Encrypt and authenticate all communication	mTLS even for internal communication
Per-session access decisions	Verify every time, continuous verification
Apply dynamic policies	Decide by context (location, time, device)
Monitor and log all access	Traceable later

Comparison with perimeter-based

	Perimeter (legacy)	Zero trust
Trust criteria	Network location	Authentication, context
Verification frequency	Once at gate	Every request
Internal communication	No encryption	Always encrypted
VPN	Central	Unneeded (move to ZTNA)
Access unit	Network	App/resource unit
Design premise	Inside is safe	Trust nothing

Perimeter is “castle + moat,” zero trust is likened to checking ID one by one no matter who arrives.

Main element 1 (ID, authentication)

The core of zero trust is a robust auth/authorization foundation. With weak identity verification, no amount of communication verification matters. IAM, MFA, passkeys, and SSO are the foundation of zero trust.

Element	Role
ID provider (Okta, Azure AD)	Centrally manage IDs
MFA required (FIDO2 recommended)	Prevent impersonation
Device authentication	Reject unmanaged endpoints
Conditional access	Decide by location/time/device
Continuous authentication	Re-verify during session

Main element 2 (ZTNA)

ZTNA is the mechanism for per-app access, replacing VPN. VPN connects you to the whole network, but ZTNA individually controls “this user can connect to only this app.” Lateral movement on VPN breach is fundamentally prevented.

Service	Characteristics
Cloudflare Access	Easy, Cloudflare-integrated
Zscaler Private Access	Enterprise
Tailscale	WireGuard-based, simple
Twingate	Developer-oriented
Palo Alto Prisma Access	Full set

ZTNA is easier to set up than VPN, with good UX too. For new builds, ZTNA over VPN is the top candidate.

Main element 3 (SASE)

SASE (Secure Access Service Edge, the cloud-integrated approach combining network and security) is a cloud service integrating network + security, gaining attention as a zero-trust implementation form. ZTNA, SWG (Secure Web Gateway), CASB, and FWaaS are provided on one platform.

Component	Role
SWG	Filter Web-borne threats
CASB (Cloud Access Security Broker, intermediary controlling SaaS use)	Visualize and control SaaS use
ZTNA	Per-app access
FWaaS	Cloud firewall
DLP (Data Loss Prevention)	Prevent sensitive-data leaks

Representative services: Zscaler, Cloudflare One, Palo Alto Prisma, Netskope.

Main element 4 (microsegmentation)

A design that finely partitions the network and minimizes inter-service communication. Using a Service Mesh (Istio, Linkerd), you can mTLS-mutual-authenticate all inter-microservice communication, preventing lateral movement to others if one service is breached.

Technology	Use case
Istio / Linkerd	Service mesh inside Kubernetes
Calico / Cilium	K8s network policies
Consul Connect	HashiCorp’s service mesh
AWS App Mesh	AWS-integrated

Main element 5 (continuous monitoring)

Zero trust’s feature is not finishing with one verification. Mechanisms continuously monitoring during sessions and immediately stripping permissions on anomaly detection are needed.

Element	Role
SIEM (Security Information and Event Management, Splunk/Sumo/Sentinel etc.)	Log integration, correlation analysis
SOAR (Security Orchestration, Automation, and Response, security-response automation)	Auto-response, playbooks
UEBA (User and Entity Behavior Analytics, anomaly detection of user behavior)	Behavior analysis, anomaly detection
XDR (Extended Detection and Response, threat detection across multiple layers)	Multi-layer integrated detection

Anomalies like “logged in at 5pm weekday → 3am from overseas IP” can be auto-detected by UEBA and temporarily suspend permissions.

Google’s BeyondCorp

The most famous implementation example of zero trust is Google’s BeyondCorp. Triggered by a 2009 attack from China (Operation Aurora), they took the bold design step of abolishing VPN entirely and treating all employees as external.

BeyondCorp features	Content
No VPN	Direct via internet
Device certificate required	Only managed endpoints allowed
Context decisions	Decide by location, device state
Per-app access	Not per network

Google employees connect to business apps the same way from anywhere - no distinction between office, home, or cafe. The state of “the concept of connecting to the corporate LAN doesn’t exist at Google.”

The December 2020 SolarWinds incident had attack code embedded in trusted monitoring software’s update files, allowing legitimate-route intrusion into about 18,000 organizations’ “insides,” including US government agencies. A path with the “trusted” label is the largest attack surface - a case driving home the necessity of zero trust.

Realistic introduction steps

Zero trust is a large-scale transformation that can’t be realized overnight. Realistically, introduce it in stages over years. All-at-once company-wide deployment freezes operations, so the standard order:

Phase	Content
Phase 1	Strengthen IAM, mandatory MFA
Phase 2	Device management, conditional access
Phase 3	ZTNA introduction, phased VPN deprecation
Phase 4	Microsegmentation, SASE
Phase 5	Continuous monitoring, UEBA introduction

“The first step is IAM + MFA strengthening.” Neglecting this and just adding ZTNA is meaningless if impersonated.

Phased zero-trust introduction roadmap

Zero trust is an organizational transformation that “doesn’t happen overnight” - a multi-year roadmap is needed. Below are realistic phases compliant with NIST SP 800-207.

Phase	Period target	Implementation	Effect
Phase 1: IAM foundation	~6 months	IdP introduction (Okta/Entra ID) + mandatory MFA	Foundation against impersonation
Phase 2: Device management	~1 year	MDM (Jamf / Intune) + device certificates	Block access from unmanaged endpoints
Phase 3: ZTNA	~1.5 years	Phased VPN → ZTNA migration (Cloudflare Access / Zscaler)	Per-app access control
Phase 4: Microsegmentation	~2 years	Service Mesh (Istio) + mTLS for all comms	Block lateral attacks
Phase 5: Continuous monitoring	~3 years	SIEM + UEBA + SOAR	Auto-detect/respond to anomalies

“Adding only ZTNA while neglecting Phase 1 (IAM + MFA) gives zero effect.” Once impersonated, everything is meaningless. Investing 6 months to 1 year in the first foundation decides the success of all of zero trust.

Zero trust starts with IAM + MFA. Without the foundation, ZTNA doesn’t work.

Decision criteria

1. Org scale

Scale	Recommended
Startup	Okta + Cloudflare Zero Trust free tier
Mid (100-1000)	Okta + Cloudflare One + MDM (Mobile Device Management)
Large enterprise	Zscaler or Palo Alto full set + SIEM
Government/finance	Custom + 24/7 SOC

2. Cloud adoption level

Use form	Recommended
SaaS-centric / cloud-first	SASE introduction is shortest
Hybrid	ZTNA + existing VPN parallel
On-prem-centric	Phase from IAM strengthening

How to choose by case

SaaS-centric startup (dozens of people, cloud-native)

Okta/Google Workspace + Cloudflare Access (free tier) + MDM. Don’t introduce VPN, ZTNA from the start. Manage company-issued Mac/PC with MDM, ban business access from personal devices. Tens of thousands of yen monthly company-wide.

Mid-size SaaS company centered on remote work

Okta + Cloudflare One (SASE) + Jamf/Intune. Centralize all SaaS via SSO, route all Web traffic through SASE cloud to apply DLP/WAF. Phase out VPN.

Large enterprise with existing on-prem assets

Azure AD + Zscaler Private Access + phased ZTNA migration + SIEM (Sentinel/Splunk). Stopping existing VPN at once stops business, so run new apps on ZTNA, existing on VPN in parallel. Replace on a 3-5 year plan.

Finance / medical / government

IdP + MFA (FIDO2) + microsegmentation + 24/7 SOC + UEBA. Implement all elements to meet NIST SP 800-207 requirements. Investment in “continuous monitoring” (UEBA, SOAR) is the most important.

Zero-trust-introduction pitfalls and forbidden moves

Here are the typical accident patterns in zero-trust introduction. All have the structure of misunderstanding “products solve it”.

Forbidden move	Why it’s bad
Misunderstand zero trust as realized by buying products	Philosophy/design/operation is the body. Just buying Okta + Cloudflare changes nothing
Abolish VPN at once to migrate to ZTNA	Existing apps stop business. New ZTNA + existing VPN parallel is realistic
Postpone IAM + MFA and only introduce ZTNA	Once impersonated, all meaningless. From foundation up in order
Allow business access from personal devices without device verification	Malware-infected endpoints connect directly to business network. MDM required
Run internal communication plaintext	Lateral attacks take all services in one shot. mTLS for all communication
Don’t aggregate audit logs in SIEM	Anomaly detection relies on manual review. Auto-correlation analysis required
Don’t monitor SaaS use with CASB	Shadow IT (unauthorized SaaS) becomes info-leak hotbed
Don’t immediately stop retirees’/transferees’ access permissions	The 2020 Twitter internal-tool breach pattern
Push zero trust by the security team alone	A company-wide transformation - cooperation among management/HR/infra/dev required
”Buying products makes you zero trust” — misunderstanding	Philosophy, design, and operations are the body; products are one implementation means
”Drop VPN and you’re zero trust” — oversimplifying	The essence is integration of IAM, devices, communication, and monitoring

The 2020 SolarWinds incident (details in appendix “Critical Incident Cases”) and the 2020 Twitter internal-tool breach (employee credential theft via social engineering, hijacking Obama/Biden/Elon Musk accounts) demonstrated the lesson that paths labeled “trusted” are the largest attack surface.

Zero trust is a philosophy and an organizational transformation. Doesn’t complete with just product introduction.

AI decision axes

AI-era favorable	AI-era unfavorable
Per-agent ID management	Common API key shared
Authorization check per action	Only at session start
All access logged	Log gaps
Short-lived tokens, auto-revoke	Permanent credentials

1. Phase from IAM + MFA — centralized IdP + FIDO2 recommended; this is the foundation of all
2. Replace VPN with ZTNA — per-app authorization fundamentally prevents lateral attacks
3. Continuous monitoring + UEBA — verify during sessions, immediate permission revocation on anomaly
4. Treat AI agents equally — separate IDs, per-action authorization, short-lived tokens

Author’s note - cases where the “trusted path” was the largest attack surface

How dangerous the premise of “the inside is trusted” is - a lesson recent large-scale incidents have driven home, told as a perennial talking point.

The December 2020 SolarWinds incident (Sunburst attack) had attack code embedded in trusted monitoring-software update files, allowing legitimate-route intrusion into about 18,000 organizations’ insides, including US government agencies (Treasury, Commerce, Homeland Security). It decisively demonstrated zero trust’s necessity that “a path labeled ‘trusted vendor’ becomes the largest attack surface,” changing CISOs’ (Chief Information Security Officer) recognition worldwide.

Another, the same-2020 Twitter internal-tool breach incident, where social engineering (spear phishing) stole some employees’ credentials, hijacking notable accounts like Obama/Biden/Elon Musk from the internal management tool. A case making clear the reality that the implicit trust of “internal tools are touched only by internal people” was actually held up by a state without MFA or device verification.

I myself, in a previous job, watched a near-miss where a retiree’s account remained valid for nearly half a year because of believing “the inside is safe” with just VPN configuration, and the person, without malice, connected to the dev environment. Both are cases where the trusted path was struck, retroactively backing up Google’s correctness in choosing to abolish VPN entirely with BeyondCorp after the 2009 Operation Aurora.

The thinking of always re-asking “who, on which device, is connecting now” is the core of zero trust.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• IdP selection (Okta / Azure AD / Google Workspace)
• Scope of mandatory MFA (company-wide / managers only)
• Device management (MDM, Jamf/Intune etc.)
• ZTNA service (Cloudflare Access etc.)
• SASE introduction necessity (company-wide SASE or phased)
• Microsegmentation (Service Mesh etc.)
• SIEM/UEBA adoption (continuous monitoring)

Summary

This article covered zero trust, including the 5 NIST SP 800-207 principles, ZTNA, SASE, microsegmentation, continuous monitoring, a phased roadmap, and AI-era design treating humans and machines equally.

Phase from IAM+MFA, replace VPN with ZTNA, verify during sessions with continuous monitoring+UEBA, treat AI agents equally. That is the practical answer for zero trust in 2026.

Next time we’ll cover secret management (storage of API keys, passwords, certificates).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.