Zero Trust & Security Architecture: Design, Segment, Verify

Most small company networks still work like a castle: one strong wall at the edge, one gate for remote staff, and everything inside trusts everything else. Zero trust replaces the question "are you inside?" with a better one, asked on every request: "who are you, on which device, in what context, and what exactly may you reach?" This lesson gives you the map of zero trust architecture, the NIST SP 800-207 vocabulary architects use, and a fully worked migration of a 25-person firm to a zero trust target design – including the access policy table that drives it.

• 12lessons in the course
• 3core NIST components
• 9rows in the worked access policy table
• ~22 minreading time for this lesson

Why the castle-and-moat network stopped working

The classic small company network grew organically: a firewall at the internet connection, a flat office LAN, file and accounting servers in a cupboard, a NAS for backups, printers, cameras, and a VPN for home working. Its security model is simple – outside is hostile, inside is trusted. Once you are on the LAN, by cable, Wi-Fi or VPN, the network stops asking questions. That model fails in three predictable ways.

1. One stolen credential opens the whole network

A VPN places the remote device on an internal segment. An attacker who phishes one VPN password arrives with the employee's full network reach – on a flat network that means every server, the backup NAS and the admin pages of switches and printers. The VPN checked identity once, then handed out network access instead of access to specific applications.

2. Lateral movement is the default

Inside a flat network, a compromised laptop can talk to every device on every port. Ransomware operators rely on this: one machine first, then discovery, credential theft and spreading to file servers and backups – the Lateral Movement tactic in MITRE ATT&CK. Any-to-any traffic offers no friction and no signal.

3. The work left the building

Mail and files moved to SaaS, staff work from anywhere, phones carry company data. Protecting the "inside" protects a shrinking part of the business.

Key terms

Implicit trust is trust granted because of where a request comes from rather than what has been verified about it. Zero trust is a set of principles that removes it: access is granted per request and per resource, based on verified identity, device state and context. Zero trust architecture (ZTA) is the enterprise design – components, policies, data flows – that applies those principles.

What zero trust is – and what it is not

Marketing has stretched the term until it means almost anything, and a fuzzy goal produces a fuzzy project. Zero trust is not a product you install; it is a property your access decisions either have or lack.

A useful test for any proposed design: pick a resource and ask, "If an attacker is already on the same network segment, what still stops them?" If the honest answer is "nothing, they are inside", the design still relies on implicit trust for that resource.

The NIST SP 800-207 model: policy engine, administrator and enforcement point

The most widely referenced vendor-neutral description is NIST Special Publication 800-207 (2020). Its value is a shared vocabulary: whatever you buy, you can describe your design with three logical components.

• Policy Engine (PE)decides: grant, deny or revoke access, using policy plus signals
• Policy Administrator (PA)executes: opens or closes the path, issues session credentials
• Policy Enforcement Point (PEP)enforces: sits in the path, allows, monitors and terminates sessions

Engine and administrator together form the policy decision point (PDP) in the control plane; the user's traffic flows through the data plane, past the PEP. A PEP can be an identity-aware proxy, a ZTNA gateway, an API gateway, a service mesh sidecar or a host agent – but all should take orders from one consistent decision source, not carry private rule sets.

The seven tenets in plain language

SP 800-207 lists seven tenets. In our own words, each with the design question it forces:

The standard describes ZTAs led by enhanced identity governance, microsegmentation or software-defined perimeters (apps hidden behind brokers). Real designs mix them; small firms usually lead with identity.

The map: pillars of a zero trust architecture

NIST names the components but not where to start. For planning, the CISA Zero Trust Maturity Model (version 2.0) uses five pillars – identity, devices, networks, applications and workloads, data – plus three cross-cutting capabilities: visibility and analytics, automation and orchestration, governance. Each pillar moves through the stages Traditional, Initial, Advanced and Optimal at its own pace. This course follows that map.

Worked example: turning a 25-person firm's castle into a zero trust design

Scenario (fictional). Alpenblick Treuhand is a fiduciary and accounting firm with 25 staff, two partners and an external IT provider. It holds tax returns, payroll data and bank statements for several hundred clients – a small business with a large data responsibility. Today it is the castle on the left of Figure 1:

The method in seven steps

1. Define the protect surface. Client data, the accounting application, the SaaS tenant, backups, and the admin accounts that control them. Five items – everything else serves them.
2. Map the transaction flows. Who talks to each item, from where, on which port? You cannot write least-privilege rules for flows you have never seen (second example below).
3. Fix identity first. One identity provider with single sign-on for the SaaS suite and, via a ZTNA broker, the accounting app. Phishing-resistant MFA (passkeys or security keys), partners and admins first. Named accounts for the IT provider.
4. Make devices a signal. Enrol company laptops and phones; "compliant" means supported OS, disk encryption, screen lock, endpoint protection running. Private laptops get browser-only mail.
5. Replace the VPN with per-app access. A ZTNA connector in the office dials out to the broker; the accounting app and archive are published individually. No inbound port stays open.
6. Segment what stays on the LAN. Staff, servers, printers and IoT, cameras, admin; guests on their own Wi-Fi. Default deny between segments.
7. Write the policy table, enforce and log it. One row per access path, each naming its enforcement point and log source. No row, no access.

The access policy table

This table is the heart of the design: readable by a partner, an auditor and the IT provider alike, and it maps one-to-one to configuration. Read each row as "who may reach what, under which conditions, enforced where, recorded how".

Notice what is not in the table: there is no row that says "VPN users may reach the office network". Every row grants one kind of access to one resource. Row P9 – the default deny – is what turns a list of permissions into a zero trust policy.

Testing the policy before anyone touches production

Before configuring products, architects test the logic. This standard-library Python script encodes rows P1 to P4 and runs realistic requests through them. It changes nothing; it makes the policy executable, so the partners see each rule's effect before anything is configured.

# zt_policy.py - evaluate access requests against a small zero trust policy table
AUTH = {"password": 0, "mfa": 1, "phishing-resistant": 2}
DEVICE = {"any": 0, "unmanaged": 0, "compliant": 1, "admin-workstation": 2}

POLICIES = {
    "accounting-app": {"groups": {"finance", "partners"}, "device": "compliant", "auth": "phishing-resistant"},
    "client-files":   {"groups": {"staff"}, "device": "compliant", "auth": "mfa"},
    "webmail":        {"groups": {"staff"}, "device": "any", "auth": "mfa"},
    "nas-admin":      {"groups": {"it-admins"}, "device": "admin-workstation", "auth": "phishing-resistant", "jit": True},
}

def decide(req):
    pol = POLICIES.get(req["resource"])
    if pol is None:
        return "DENY", "no policy for resource (default deny)"
    if not pol["groups"] & req["groups"]:
        return "DENY", "user not in an allowed group"
    if DEVICE[req["device"]] < DEVICE[pol["device"]]:
        return "DENY", f"device is {req['device']}, policy needs {pol['device']}"
    if AUTH[req["auth"]] < AUTH[pol["auth"]]:
        return "STEP-UP", f"signed in with {req['auth']}, policy needs {pol['auth']}"
    if pol.get("jit") and not req.get("jit_grant"):
        return "DENY", "no active just-in-time grant"
    return "ALLOW", "all conditions met"

REQUESTS = [
    {"user": "anna",  "groups": {"staff", "finance"},  "device": "compliant", "auth": "phishing-resistant", "resource": "accounting-app"},
    {"user": "marco", "groups": {"staff"},             "device": "unmanaged", "auth": "mfa",                "resource": "webmail"},
    {"user": "marco", "groups": {"staff"},             "device": "unmanaged", "auth": "mfa",                "resource": "client-files"},
    {"user": "lea",   "groups": {"staff", "partners"}, "device": "compliant", "auth": "mfa",                "resource": "accounting-app"},
    {"user": "tom",   "groups": {"staff", "it-admins"},"device": "admin-workstation", "auth": "phishing-resistant", "resource": "nas-admin"},
    {"user": "tom",   "groups": {"staff", "it-admins"},"device": "admin-workstation", "auth": "phishing-resistant", "resource": "nas-admin", "jit_grant": True},
    {"user": "anna",  "groups": {"staff", "finance"},  "device": "compliant", "auth": "phishing-resistant", "resource": "printer-admin"},
]

for r in REQUESTS:
    verdict, reason = decide(r)
    print(f"{verdict:8} {r['user']:6} -> {r['resource']:15} {reason}")

Run it with python3 zt_policy.py. This is the output it prints:

ALLOW    anna   -> accounting-app  all conditions met
ALLOW    marco  -> webmail         all conditions met
DENY     marco  -> client-files    device is unmanaged, policy needs compliant
STEP-UP  lea    -> accounting-app  signed in with mfa, policy needs phishing-resistant
DENY     tom    -> nas-admin       no active just-in-time grant
ALLOW    tom    -> nas-admin       all conditions met
DENY     anna   -> printer-admin   no policy for resource (default deny)

Reading the result like an architect

• Marco on his private laptop gets mail but not the client archive: client data stays on devices whose health the firm can see.
• Lea used a one-time code. She is not denied but asked to step up to her passkey – productive for her, a clear reason in the log.
• Tom is a real admin on a real admin workstation and is still denied until his just-in-time request is approved. Standing admin rights are what attackers hunt for.
• The printer admin page has no policy, so even Anna with the strongest sign-in is refused. Strong authentication never replaces an explicit permission.

A toy, but a professional habit: every decision must be explainable in one line.

Under the hood: one access request, step by step

What happens when Anna opens the accounting application at 08:05 from home? Following one request through the components shows where each control lives – and where it can fail.

1. 08:05:02 – Request interceptedAnna opens acct.alpenblick.example. The ZTNA client recognises a published application and sends the request to the broker.
2. 08:05:03 – AuthenticateThe broker (the PEP) finds no valid session and redirects the browser to the identity provider via OpenID Connect.
3. 08:05:08 – Phishing-resistant sign-inAnna unlocks her passkey with her fingerprint; the authenticator signs a WebAuthn challenge with a private key that never leaves the device and is bound to the identity provider's domain.
4. 08:05:09 – Signals and decisionThe policy engine reads her groups, the authentication method, the device record (managed, compliant, last check-in 12 minutes ago) and the sign-in risk. Policy P2 matches; the administrator tells the broker to open a path to this one application.
5. 08:05:10 – Data planeLaptop → broker → connector (dialled out from the office) → accounting server. The connector reaches only that server and port.
6. 10:40 – Signal changesEndpoint protection on the laptop stops. The device is no longer compliant; the engine revokes the decision and the broker ends the session.

Every step writes a record. A decision record from such a system looks roughly like this (example record – field names differ between products):

{
  "time": "2026-03-02T08:05:09Z",
  "subject": "anna@alpenblick.example",
  "groups": ["staff", "finance"],
  "auth": {"method": "passkey", "phishing_resistant": true},
  "device": {"id": "LT-014", "managed": true, "compliant": true, "last_checkin_min": 12},
  "resource": "accounting-app",
  "policy": "P2",
  "decision": "allow",
  "session_ttl_min": 480,
  "enforced_by": "ztna-broker"
}

Why the 10:40 step is the hard part

Granting access is easy; revoking it promptly is where designs fall short. If the app only checks a token issued at 08:05 with an eight-hour lifetime, a laptop that turns unhealthy at 10:40 keeps access until 16:05. Three techniques close the gap: short lifetimes for sensitive apps, enforcement points that re-check posture during the session, and event-driven revocation, where the identity or device system pushes signals such as "device no longer compliant" to the enforcement points. The OpenID Foundation's Shared Signals Framework, with its Continuous Access Evaluation Profile (CAEP), standardises such signals; product support varies, so test it.

Second example: map the flows before you segment

Mapping transaction flows is the step most teams skip – and the reason segmentation projects break printers, scanners and backups on day one. The architect exports a normal week of connection records from Alpenblick's current firewall. Documentation addresses (RFC 5737) stand in for the internal range. Input: an inventory mapping addresses to roles, and the records reduced to source, destination and port.

# hosts.csv              # flows.csv (excerpt of one week)
ip,role                  src,dst,dport
192.0.2.5,file-server    192.0.2.21,192.0.2.5,445
192.0.2.6,accounting-db  192.0.2.22,192.0.2.5,445
192.0.2.9,printer        192.0.2.23,192.0.2.5,445
192.0.2.21,laptop        192.0.2.21,192.0.2.6,1433
192.0.2.22,laptop        192.0.2.22,192.0.2.6,1433
192.0.2.23,laptop        192.0.2.21,192.0.2.9,9100
192.0.2.40,it-pc         192.0.2.40,192.0.2.5,445
192.0.2.50,camera-nvr    192.0.2.40,192.0.2.6,1433
                         192.0.2.40,192.0.2.21,3389
                         192.0.2.50,192.0.2.5,445
                         192.0.2.6,192.0.2.5,445

(Two separate CSV files, shown side by side.) The script groups records by role, because rules are written for roles, not addresses:

# flowmap.py - turn raw connection records into a role-to-role flow map
import csv
from collections import Counter

roles = {row["ip"]: row["role"] for row in csv.DictReader(open("hosts.csv"))}
flows = Counter()
for row in csv.DictReader(open("flows.csv")):
    key = (roles.get(row["src"], "UNKNOWN"), roles.get(row["dst"], "UNKNOWN"), row["dport"])
    flows[key] += 1

print(f"{'source role':14} {'destination role':16} {'port':>5} {'records':>7}")
for (src, dst, port), n in sorted(flows.items()):
    print(f"{src:14} {dst:16} {port:>5} {n:>7}")

Running python3 flowmap.py on these two files prints:

source role    destination role  port records
accounting-db  file-server        445       1
camera-nvr     file-server        445       1
it-pc          accounting-db     1433       1
it-pc          file-server        445       1
it-pc          laptop            3389       1
laptop         accounting-db     1433       2
laptop         file-server        445       3
laptop         printer           9100       1

Turning the flow map into decisions

• laptop → file-server :445, laptop → accounting-db :1433. Expected, but both move to the ZTNA broker – also in the office: one path, one policy, one log. (Clients on the database port are a finding in themselves.) Printing on :9100 becomes rule P6.
• camera-nvr → file-server :445. Nobody expected it: the recorder exports clips to a share. Stop the export, keep cameras isolated (P7). Surprises like this are why you map first.
• accounting-db → file-server :445. A nightly export. Legitimate need, wrong place: it moves to the NAS with a dedicated backup account.
• it-pc → laptop :3389. Remote desktop from a normal PC becomes time-boxed support via the broker (P5) or the admin workstation (P4).

What went wrong if you see UNKNOWN? An address is in the records but not the inventory – an inventory gap or something that should not be there. Write no rule for it until you know.

What stays on the LAN becomes a short default-deny rule set. On a Linux router with nftables (interface names are examples):

table inet office {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop
    iifname "vlan20" oifname "vlan40" tcp dport 9100 accept comment "P6 staff to printers"
    iifname "vlan60" oifname { "vlan30", "vlan40", "vlan50" } tcp dport { 22, 443 } accept comment "P4 admin segment"
    iifname "vlan30" oifname "wan" tcp dport 443 accept comment "connector dials out to broker"
    iifname "vlan50" oifname "wan" ip daddr 203.0.113.10 tcp dport 443 accept comment "P7 camera updates"
    iifname { "vlan20", "vlan70" } oifname "wan" accept comment "staff and guests to internet"
    counter log prefix "zt-deny " drop comment "P9 default deny"
  }
}

Check the syntax without loading it: sudo nft -c -f office.nft prints nothing when the file is valid and an error with a line number when not. The last rule matters most: denied traffic is counted and logged, so the first week tells you exactly which forgotten flow broke.

Common mistakes in zero trust projects

Zero trust projects rarely fail because a product is weak. They fail on order, scope and forgotten edge cases.

Troubleshooting: symptoms, causes and fixes

How experienced architects run a zero trust rollout

Professionals do not start with a product shortlist. They start with the business, design on paper, then prove each step on a small group. A typical sequence for a firm like Alpenblick (your timing will differ):

1. Phase 0 – UnderstandProtect surface, inventories, current access paths, decision-makers. Output: a one-page protect surface and a draft policy table.
2. Phase 1 – IdentitySingle sign-on, phishing-resistant MFA (admins and partners first), break-glass accounts, no shared accounts.
3. Phase 2 – DevicesEnrol devices, define compliance, report-only, then require compliance for client data.
4. Phase 3 – Access pathsPublish apps through ZTNA, pilot with finance, run in parallel, retire the VPN group by group.
5. Phase 4 – Network and adminsSegment the LAN from the flow map; admin work on a dedicated workstation with just-in-time elevation.
6. Phase 5 – OperateCentral logs, monthly review of denies and exceptions, quarterly access review, maturity check per pillar.

Heuristics that save weeks

• Report-only before enforce. Most identity platforms can log what a rule would have done. A week of that data beats any design meeting.
• Guard the control plane. Whoever administers the identity provider or broker can rewrite every policy; those roles get the strongest protection.

Thinking errors of experts: network specialists over-trust segmentation; identity specialists forget that a compromised server talks to every neighbour. Almost everyone underestimates discovery.

The defender's view: proving the design works

A policy that is not tested is an assumption. Zero trust gives defenders what a castle never did: many small enforcement points and a log record for every decision.

What to monitor from day one

• Sign-ins: legacy protocols that bypass MFA, newly registered MFA methods (a classic step after account takeover), countries without staff.
• Changes: every change to access rules, broker apps, compliance settings and admin roles alerts a second person.
• Deny spikes (broken workflow or probing) and any break-glass use.

Tests that prove the controls (on your own systems)

That is why the example began with identity; in data centre-heavy enterprises, microsegmentation moves up.

Small business or enterprise: same principles, different shape

The tenets do not change with size; the enforcement points and the order of work do.

Check yourself: zero trust fundamentals quiz

You can now…

• Explain why castle-and-moat fails – one check at the edge, lateral movement inside.
• Define zero trust and ZTA – and spot common misreadings.
• Name the NIST SP 800-207 components – policy engine, policy administrator, enforcement point; control and data plane.
• Use the pillar map – five pillars, three cross-cutting capabilities.
• Write an access policy table – who, what, conditions, decision, enforcement point, log source, default deny.
• Map flows before segmenting – and treat unknown or surprising flows as findings.
• Plan a phased rollout – identity first, report-only before enforce, VPN retired group by group.
• Prove controls with tests – each with an expected result and log evidence.

Glossary