A financial services firm we work with had a problem they didn’t know they had. Their perimeter firewall was clean. Antivirus showed no alerts. The SOC hadn’t received a priority ticket in three weeks. What they did have was a threat actor who had been living inside their network for 47 days, moving laterally from a compromised helpdesk workstation toward domain controllers via T1021.002 — SMB/Windows Admin Shares.
The entry point wasn’t exotic. A phishing email hit a contractor account. That account had VPN access. VPN access meant full network trust. Full network trust meant the attacker had the same reach as any legitimate employee. Classic flat network problem — and the exact scenario that makes zero trust architecture not a buzzword but a structural necessity.
That engagement kicked off a six-month Zero Trust rollout. Here’s what actually happened — including where we got it wrong.
Why Perimeter Security Still Gets Deployed (And Why It Will Fail You)
The castle-and-moat model made sense when everyone worked in one building and everything sat on-premises. That world ended around 2015. By 2020 it was completely gone.
The problem isn’t that firewalls are useless — they’re still part of the stack. The problem is that organizations treat firewall access as equivalent to trust. Once inside the perimeter, lateral movement is trivial. APT29, Lazarus Group, and every ransomware affiliate worth naming exploit flat networks as a core part of their playbook. It’s T1021 and T1550 executed against an environment that has no internal enforcement boundaries. The attacker isn’t breaking in — they’re walking through an open door that was left open for everyone else.
Zero Trust flips the assumption: no user, no device, no network segment gets implicit trust. Every access request is verified. Every session is evaluated. Trust is granted per-resource, per-session, based on identity, device posture, and context.
That’s the principle. The implementation is messier.
Designing the Architecture Before We Touched a Single Firewall Rule
The first thing we did was stop the client from opening a vendor portal. Everyone wanted to start buying tools. We needed an architecture document first.
Zero Trust isn’t a product. NIST SP 800-207 frames it as a set of logical components: policy engine, policy administrator, policy enforcement point. You can buy technology that maps to each of those, but without a clear design you end up with three overlapping tools doing the same job and none of them talking to each other.
We mapped their asset inventory, identified crown jewels (finance systems, Active Directory, customer database), charted all access paths, and defined trust levels for each resource tier. That alone took three weeks. It was the most valuable three weeks of the project.
Identity as the New Perimeter
We built on Microsoft Entra ID (formerly Azure AD) because the client was already on Office 365. That made Conditional Access the natural policy enforcement layer. We enforced phishing-resistant MFA across all accounts — Microsoft Authenticator with number matching for general users, FIDO2 hardware keys (YubiKey 5 series) for privileged accounts. Privileged Identity Management was configured so admin roles require just-in-time activation with business justification. No permanent role assignments.
For reference, Microsoft Learn’s Conditional Access documentation is solid and we worked from it extensively during policy design.
One early mistake: we applied the most restrictive Conditional Access policy to all users simultaneously and broke remote access for the entire sales team on a Monday morning. Lesson learned — always start with report-only mode. The Conditional Access insights workbook shows exactly who would have been blocked before you flip to enforcement. That one mistake cost us two hours of emergency triage and one very unhappy VP of Sales.
Microsegmentation: Where We Made Our First Real Error
The client’s network was completely flat — a single /16 subnet with over 400 hosts. Everything could talk to everything. We used Azure Network Security Groups for cloud workloads and on-prem VLANs enforced through Cisco ISE for the datacenter. The goal: a compromised endpoint in the finance VLAN could not initiate connections to HR systems or reach domain controllers directly.
Our first segmentation pass was too aggressive. We blocked SMB between segments without accounting for a legacy application that depended on UNC path file access to function. The app broke silently — users couldn’t print, and it took four hours to identify the blocked port as the cause. After that incident, we instituted a two-week observation window using Zeek to capture all network flows before enforcing any new rule. Map before you block. Always.
Building the Policy Engine
The policy engine determines whether a given access request gets granted, denied, or challenged. In our implementation it had three inputs: identity, device posture, and context (location, time, behavioral signals).
Device Trust Scoring
We enrolled all managed endpoints in Microsoft Intune and configured compliance policies checking OS patch level (required within 30 days of Patch Tuesday), BitLocker status, Defender for Endpoint with real-time protection active, and no jailbreak or rooted state on mobile devices. Non-compliant devices could not satisfy Conditional Access requirements. Full stop. No grace periods after the first 60 days of rollout.
We also deployed CrowdStrike Falcon on all endpoints and configured it to push device health signals into Conditional Access via third-party compliance integration. If Falcon flagged an endpoint as compromised, that machine’s compliance status flipped to non-compliant immediately — blocking access in near real-time without waiting for manual intervention. Real-time EDR signal feeding real-time access decisions.
For workload hardening, CIS Benchmarks provided the baseline for Windows Server 2022 and Ubuntu 22.04 LTS. We automated compliance checking with PowerShell DSC on Windows and OpenSCAP on Linux, with results feeding into Sentinel for drift detection.
Conditional Access Policies in Practice
We ended up with 14 named Conditional Access policies covering different user populations and resource sensitivities. Finance application access required a compliant managed device, phishing-resistant MFA, blocked any country outside the client’s operational regions, and limited sessions to 4 hours before requiring re-authentication.
Privileged admin access got the most scrutiny. T1078 (Valid Accounts) consistently ranks in the top 10 most observed MITRE ATT&CK techniques, and credential abuse is the initial access vector we see most often across incident response engagements. Admin access required a FIDO2 hardware key, was restricted to named admin workstations only, required PIM activation with a written justification, and all sessions were recorded via Microsoft Defender for Cloud Apps.
The cascading failure risk with Conditional Access policies is real — the same pattern we documented in our Windows Group Policy incident post-mortem applies directly here. Get a second set of eyes on every policy before enforcement mode. A misconfigured exclusion in a Conditional Access policy can create a gap wider than no policy at all.
The Part Nobody Warns You About: Log Everything
Zero Trust without full logging visibility is just an expensive firewall. The architecture only works if you can detect policy violations, investigate anomalies, and respond to incidents in time to matter.
We centralized logs into Microsoft Sentinel with the following data connectors active: Entra ID sign-in and audit logs, Defender for Endpoint alerts and device telemetry, Cisco ISE network access logs, Azure Firewall and NSG flow logs, and DNS query logs via Defender for DNS. Every policy enforcement point had to feed the SIEM. No exceptions.
We wrote custom KQL detection rules for high-risk patterns: impossible travel (sign-in from two geographically separated countries within 2 hours), admin role activation outside business hours, SMB traffic initiated from a non-server endpoint toward domain controllers, and any device triggering lateral movement indicators consistent with T1021. The rules aren’t complex — the discipline is in making sure every enforcement point is logging in the first place.
This detection-first posture builds directly on the methodology in our threat hunting and SOC readiness audit guide. If your SOC isn’t built to hunt, a Zero Trust rollout will surface detections you’re not ready to triage. Build detection capability before you build enforcement capability.
The client also needed assurance that backup and archival systems weren’t operating as unmonitored side channels. We integrated their managed backup infrastructure into the same identity and access controls — backup access authenticated through Entra ID, scoped to specific admin roles, with all access events flowing into Sentinel alongside everything else. An attacker who can’t access production systems but can access unprotected backups still wins.
The Honest Limitations of This Architecture
Zero Trust does not protect you from a compromised identity presenting a clean device. If an attacker phishes credentials and the MFA prompt is approved — MFA fatigue attack, T1621 — the policy engine sees a valid user on a compliant device and grants access. That’s exactly why anomaly detection and UEBA are not optional add-ons. You’re looking for behavioral signals the policy engine can’t evaluate at authorization time: unusual data access volumes, off-hours file enumeration, lateral movement patterns that look like a user but don’t behave like one.
Legacy applications are the other hard constraint. About 20% of this client’s application estate couldn’t integrate with modern identity providers. For those, we implemented application proxy solutions and isolated network segments, but the access controls are weaker than the rest of the environment. Technical debt is a security debt. It doesn’t disappear because you deployed a modern identity platform around it — it just becomes the most visible gap in an otherwise tighter architecture.
The SANS reading room has solid material on Zero Trust edge cases, particularly for OT/ICS environments where this architecture requires significant adaptation. Industrial control systems don’t fit neatly into a Conditional Access framework. If you’re running operational technology, the playbook is materially different.
Six Months In: What the Numbers Show
Six months after full enforcement, the metrics moved in the right direction. Lateral movement attempts detected by Sentinel: 3 (all traced to misconfigured service accounts, no active threat actors). MFA-blocked sign-in attempts from outside the client’s operational regions: 847. Privileged account activations outside business hours triggering alerts: 12 (6 were legitimate emergency access, 6 were policy violations that resulted in documented retraining). Mean time to detect for policy violation events: under 8 minutes.
The architecture didn’t make them immune. It made them visible. That’s the actual value — you stop operating in the dark and start having an opinion about every access event in your environment.
What to Prioritize if You’re Starting This Tomorrow
Don’t try to boil the ocean. Zero Trust is a journey, not a deployment date. Based on outcomes across client engagements, here’s the sequencing that delivers the most risk reduction per unit of effort:
- Enforce phishing-resistant MFA on all privileged accounts first. This week, not next quarter.
- Get device inventory and compliance visibility before touching network segmentation.
- Deploy report-only Conditional Access policies and analyze the data for at least 30 days before moving to enforcement.
- Segment your crown jewels from the general user network as your first microsegmentation target — not everything at once.
- Build your SIEM detection rules before enforcement goes live. Visibility before policy, every time.
My opinionated take: most organizations spend 80% of their Zero Trust budget on enforcement technology and 20% on detection. That ratio should be closer to 50/50. You can’t respond to what you can’t see.
If you want to pressure-test your current architecture or scope a Zero Trust rollout for your environment, reach out to the team at SSE. The assessment typically runs two weeks, and the findings are almost always more urgent than clients expect going in.
