The Zero Trust Framework

In the intro to this series, we defined Zero Trust as a framework that guides an organization’s strategic, operational, and technical behaviours, operating on the assumption that threats exist inside and outside the environment. In this post, we’ll extend that perspective and propose an framework organizations can use on the road to Zero Trust.

~ The Traditional Network Security Architecture ~

Consider a company with a single office, several teams, and a mix of technologies on the network. Traditional network security architectures segment the environment often by team, function, and/or resources using controls like VLANs on a Layer-3 switch, router, or firewall. In many SMB and mid-market deployments this function is collapsed into a single device (for example, a Cisco Meraki MX-series firewall).

North/South traffic is any flow that crosses a trust boundary, classically referred to as, the network or enterprise “edge” to or from the internet. Outbound (egress) flows move “north”; inbound (ingress) flows move “south.”

East/West traffic is lateral movement within the enterprise, for example a user on the End User Devices segment talking to an Application on the Servers and Services segment.

Now, let's scale the concepts to multiple sites, a WAN, data centres, cloud platforms, and SaaS - the cardinal model still applies, but the boundary that defines North/South becomes contextual. Traffic between two corporate sites over a private WAN is usually East/West. If that same path transits an untrusted or third-party network, many teams treat it as North/South relative to that boundary.

Throw in real world considerations - End User VPNs, Remotely available Services, Terminal Services, Site to Site VPNs to 3rd Parties like Contractors, etc., networks can become quite challenging to define, control, and secure.

Zero Trust enters the chat...

This ambiguity is one reason Zero Trust is so useful: it replaces a single, static perimeter with resource-centric boundaries and consistent policy wherever access occurs.

Zero Trust doesn’t pretend the perimeter doesn’t exist; it de-emphasizes it as the sole control point. Defenses move from broad, network perimeters to users, devices, applications, and data, with policy enforced close to the resource and continuously evaluated. Every attempt to access a resource is mediated by two (2) logical components:

• Policy Decision Point (PDP) - Evaluates the context and policies to determine access.

• Policy Enforcement Point (PEP) - In line with the path to enable, monitor, and terminate connections according to the PDP.

This architecture assumes "breach", applies least privilege, and continuously verifies identity, device health, and context not just at the perimeter, but everywhere.

~ The Classical AAA Model ~

AAA still matters, however the Zero Trust framework extends the classic AAA model by requiring continous checks and fine-grained policy tied to identify, posture, context, and data.

• Authentication - Verification of Identity.

• Authorization - Validation of Permission.

• Accounting (or Auditing) - Logging / Tracking / Auditing behavior.

The Zero Trust Framework leverages a layered approach to security expanding on the fundamental AAA perspective:

AAA Component	Traditional AAA Focus	Zero Trust Expansion
Authentication (Who are you?)	One-time identity verification at login or network perimeter. Examples: username/password, basic MFA, VPN login.	Continuous identity assurance using phishing-resistant MFA (FIDO2, PIV), risk-based and contextual checks (geo, time, device posture). Identity validation occurs before and during sessions, not just at the start.
Authorization (What are you allowed to do?)	Role-based or group-based access control, often broad and static. Policies enforced mainly at network perimeter or application entry.	Dynamic, granular policy enforcement using least privilege and “just-in-time” access. Policies adapt in real time to context (user role, device health, sensitivity of resource, workload identity). Applied at Policy Enforcement Points (PEPs) across both North/South and East/West flows.
Accounting / Auditing (What did you do?)	Logging for compliance or forensics, often siloed and periodic. Focus on recording activity after events.	Real-time visibility and analytics across all transactions. Logs integrated into threat detection, behavior analytics, and automated response. Auditing includes validation of continued compliance and access rights.
— Zero Trust Additions —	(Not explicit in classic AAA)	Re-Validation: Periodic or event-driven re-check of identity, device posture, and policy adherence.
Session Termination/Quarantine: Automated revocation or isolation when risk changes.
		Everywhere Enforcement: Controls are enforced close to the resource, not just at the edge.

~ The Five Pillars of the Zero Trust Framework ~

The gold standard of Zero Trust is CISA's ZTMM Pillars. We'll expand further on subsequent posts which will dig a layer deeper into each pillar.

• Identity – strong auth, risk-adaptive access, phishing-resistant MFA, continuous evaluation.

  
  

• Device – posture assessment, compliance attestation, and isolation/quarantine paths.

  
  

• Network/Environment – software-defined segmentation, PEPs near resources, encrypted transport everywhere.

  
  

• Application & Workload – per-app policy, service identity, micro-segmentation, and secure SDLC.

  
  

• Data – classification, tokenization/ENCRYPTION, and policy-driven access to sensitive data.

Zero Trust isn’t about tearing down the perimeter, it’s about making every request prove it belongs. By extending AAA with continuous verification and applying the five pillars across every flow, you shift from a single line of defense to a living, adaptive security posture. Start small, build consistently, and make trust earned, not assumed.