In my previous blog post, I explored how attackers no longer break in, they log in, using valid credentials and identities to move through environments undetected.
If identity is now the primary attack vector, then traditional perimeter-based security models are no longer sufficient.
Attackers no longer “storm the perimeter” because there is no single perimeter. Employees and contractors work from home, branch offices and public clouds, while business processes span SaaS platforms and operational‑technology (OT) networks.
Traditional perimeter-based approaches break down as organizations adopt cloud services, remote work, and hybrid IT environments, making it increasingly difficult to define or enforce a single network boundary.
Lateral movement inside flat networks lets adversaries pivot from a single compromised endpoint to high‑value systems. Zero‑trust architecture (ZTA) replaces implicit trust with continuous verification for users, devices and sessions. It treats every access request as untrusted, re‑evaluating the session whenever risk factors change.
Federal policy has accelerated adoption; the U.S. Office of Management and Budget’s Memorandum M‑22‑09 established a government‑wide zero‑trust strategy, influencing state and local procurement requirements and cyber‑security questionnaires. The result is that ZTA is no longer an optional best practice; it is becoming a regulatory requirement for public‑sector bodies and a contractual expectation for private suppliers.
ZTA rests on two axioms: never trust, always verify and assume breach. A zero‑trust system continuously authenticates users and devices, authorises requests based on least‑privilege policies and monitors sessions for anomalies. Zero trust emphasizes continuous authentication and authorization for every user, device and application, operating under the principle of “never trust, always verify”. Zero‑trust models treat every access request as potentially malicious and require verification to occur continuously rather than at a single authentication point. Because decisions are based on identity, device posture and context rather than location, identity becomes the new perimeter.
Modern ZTA implementations share several core pillars:
Most breaches succeed because attackers move laterally from an initial foothold to other systems. Micro‑segmentation divides networks into small zones (often down to the workload or container) and restricts communications based on identity and context. Identity‑aligned micro‑segmentation enforces least privilege and adapts as the network changes, ensuring that stolen credentials do not grant full access. CISA guidance emphasizes that it significantly enhances security by limiting the impact of a compromise and that solutions should enable policy‑controlled access based on identity, device posture and behavioral indicators.
Micro‑segmentation uses software‑defined networking (SDN), host‑based firewalls and virtual overlays to enforce least‑privilege policies across hybrid and multi‑cloud environments. Continuous monitoring and logging are required to adjust policies dynamically. In practice, micro‑segmentation goes beyond VLANs; policies follow identities and workloads rather than IP addresses. For example, segmentation rules might allow a database pod in Kubernetes to accept traffic only from application pods with the label role=backend.
Kubernetes NetworkPolicies provide a declarative way to enforce micro‑segmentation between pods. The following YAML manifests create a namespace for an internal service and allow inbound traffic only from pods with a specific label. All other traffic is denied by default:
| apiVersion: v1 kind: Namespace metadata: name: finance --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-finance-backend namespace: finance spec: podSelector: matchLabels: role: backend ingress: - from: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 5432 policyTypes: - Ingress |
This policy defines a finance namespace and allows pods labelled role=api to connect to database pods labelled role=backend on port 5432. All other inbound traffic is implicitly denied. Applying such policies across namespaces prevents lateral movement between workloads and implements least‑privilege communication at the network layer.
For workloads running on Linux hosts, you can enforce micro‑segmentation with iptables or nftables. The following script restricts SSH access to a database server from a specific application subnet while denying all other SSH attempts:
| #!/bin/bash # Flush existing rules iptables -F # Default deny for SSH iptables -A INPUT -p tcp --dport 22 -j DROP # Allow SSH from application subnet 10.10.20.0/24 iptables -A INPUT -p tcp -s 10.10.20.0/24 --dport 22 -j ACCEPT # Allow established connections iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Allow loopback traffic iptables -A INPUT -i lo -j ACCEPT # Drop everything else iptables -A INPUT -j DROP |
This script flushes existing firewall rules and applies a deny‑by‑default policy. Only hosts in the application subnet can initiate SSH connections to the database server. Such host‑level micro‑segmentation complements network‑level segmentation and is particularly useful in bare‑metal or virtualised environments.
Many authentication systems evaluate trust only at login. Zero‑trust models require continuous validation, monitoring the entire session and re‑evaluating risk whenever context changes. Just‑in‑time access generates temporary credentials, automatically expires them after the session, dynamically scopes privileges and continuously revalidates access requirements. Traditional remote‑support tools struggle with this requirement because they lack integration with security monitoring systems and cannot enforce dynamic policy changes mid‑session.
The following Python code snippet illustrates how to implement continuous access evaluation (CAE) for API tokens. It decodes a JSON Web Token (JWT), verifies its signature, checks its expiration and consults an identity provider for revocation events. If the token is invalidated due to a password reset or elevated risk, the system forces re‑authentication. This pattern echoes Microsoft’s Continuous Access Evaluation design, where resource APIs listen for events from the identity provider and invalidate tokens when conditions change.
| import jwt # PyJWT: install with `pip install PyJWT` import requests from datetime import datetime, timezone PUBLIC_KEY = open('idp_public_key.pem').read() IDP_EVENTS_ENDPOINT = 'https://idp.example.com/events' def validate_token(token: str) -> bool: try: # Decode and verify signature claims = jwt.decode(token, PUBLIC_KEY, algorithms=['RS256'], options={'verify_aud': False}) exp = datetime.fromtimestamp(claims['exp'], tz=timezone.utc) if exp < datetime.now(tz=timezone.utc): return False # Check for revocation events user_id = claims['sub'] events = requests.get(f"{IDP_EVENTS_ENDPOINT}?user={user_id}").json() for event in events: if event['type'] in {'password_reset', 'mfa_enrolled', 'risk_detected'}: return False return True except (jwt.InvalidTokenError, KeyError): return False # Example usage within an API endpoint def protected_endpoint(token: str): if not validate_token(token): raise Exception('Access denied: token invalid or requires re‑authentication') # Proceed with the API call return 'Sensitive data' |
This function decodes the JWT with the identity provider’s public key, checks its expiry and queries the identity provider’s events API for revocation signals such as a password reset or elevated user risk. A production implementation would integrate with the identity provider’s event system or webhook. By evaluating every request rather than relying on token lifetime, the application enforces continuous session validation.
In a zero‑trust model, identity is the control plane. An effective Zero‑Trust roadmap begins with strong IAM: standardized multi‑factor authentication, elimination of shared accounts and automated user provisioning and de‑provisioning. Identity governance reduces risk immediately and generates audit‑ready evidence that supports regulatory and procurement requirements. Public‑sector agencies like those in Texas and New Mexico align their internal controls with state security catalogs to simplify audit preparation and vendor compliance.
Identity‑aligned micro‑segmentation ties network policies to user and device identities. Policies follow the user and device across cloud and on‑prem environments rather than relying on IP addresses. For example, an organization might use the Open Policy Agent (OPA) to evaluate access requests based on user attributes, device posture and resource sensitivity. The following Rego policy ensures that only engineers with approved device posture can access a production service:
| package zero_trust.authz default allow = false allow { input.user.role == "engineer" input.user.mfa == true input.device.compliant == true input.resource.env == "prod" input.action == "read" } allow { input.user.role == "engineer" input.user.mfa == true input.device.compliant == true input.resource.env == "prod" input.action == "write" input.user.change_request == true } |
The policy denies all requests by default. It permits read access to production resources only if the user is an engineer, has MFA enabled and is using a compliant device. Write access requires an approved change request. Embedding such policies into Kubernetes admission controllers or API gateways enforces least privilege at runtime and simplifies audits.
Zero trust is no longer a voluntary framework; it is rapidly becoming a compliance mandate. Executive Order 14028 required U.S. federal agencies to create a Zero‑Trust implementation plan and that the OMB’s Memorandum M‑22‑09 set a prescriptive timeline for agencies to achieve specific zero‑trust security goals by the end of fiscal year 2024. These mandates established zero trust as the baseline for government systems and influenced state and local governments, contractors and suppliers. CISA’s Zero‑Trust Maturity Model sets de facto standards even without legal mandates; its cross‑sector cyber goals encourage organizations to invest in identity, network segmentation, continuous monitoring and automated orchestration. The same budget guide warns that healthcare organizations must prepare for proposed HIPAA updates that will elevate network segmentation from an “addressable” to a mandatory requirement and notes that cyber‑insurance providers already require documented micro‑segmentation implementations for coverage. In manufacturing and industrial environments, FDA guidance on securing operational‑technology calls for zone‑based architectures following IEC 62443 standards.
Implementing zero trust helps organizations demonstrate compliance with various frameworks. Mapping policies to NIST SP 800‑207, the CISA model and sector‑specific regulations reduces audit friction. Organizations should document how identity controls, micro‑segmentation, continuous monitoring and data protection practices align with these frameworks and produce evidence of enforcement (e.g., logs, policy files and security assessments).
Adopting zero trust is a program, not a product. The following roadmap outlines steps security architects can take to implement zero trust across hybrid and cloud environments:
Zero‑trust architecture is more than a buzzword, it is a necessary response to the dissolution of network perimeters and the rise of sophisticated, AI‑driven attacks. Perimeter‑based security models have failed in the face of remote work and dynamic cloud services, while modern threats exploit lateral movement within flat networks.
ZTA meets this challenge through continuous authentication, identity‑aligned micro‑segmentation and context‑aware session monitoring. Implementing ZTA in hybrid and cloud environments requires careful planning, discovering assets, strengthening identity, segmenting networks, adopting continuous access evaluation and integrating telemetry.
Regulatory mandates like EO 14028, OMB M‑22‑09 and sector‑specific regulations make zero trust the baseline for public‑sector bodies. By following a structured roadmap, leveraging tools like Kubernetes Network Policies, host firewalls, Open Policy Agent and continuous token validation, and partners like us at Arctiq security practitioners can build scalable, resilient zero‑trust architectures that protect critical assets, satisfy compliance requirements and support the business in 2026 and beyond.
For a deeper look at applying Zero Trust in practice, see our approach using HashiCorp Boundary and Vault. For a broader perspective on why Zero Trust matters in distributed environments, see this article.
Ready to implement Zero Trust across your hybrid and cloud environments? Contact us to get started.