Cybersecurity Guide

Zero Trust Security
Implementation Guide

Build a Zero Trust architecture that eliminates implicit network trust — covering identity-centric access, device posture validation, micro-segmentation, ZTNA deployment on FortiGate and Azure AD, least privilege enforcement, and continuous behavioral monitoring for Indian enterprises.

📅 March 2026
⏱️ 24 min read
🏷️ ZTNA · MFA · Micro-segmentation · FortiGate · Azure AD · SASE
✍️ EnterWeb IT Firm

📋 In This Guide

The traditional "castle-and-moat" security model — trust everything inside the network perimeter, block everything outside — is fundamentally broken in the modern enterprise. Remote workers access resources from home networks and coffee shops. Applications live in AWS, Azure, and SaaS platforms, not in the datacenter. Contractors, partners, and vendors need access to specific systems without joining the corporate network.

Zero Trust replaces perimeter trust with a simple principle: never trust, always verify — every access request is authenticated, authorized, and continuously validated regardless of where it originates. This guide walks through implementing Zero Trust systematically, starting with the identity foundation and progressing through device trust, network segmentation, ZTNA, and behavioral analytics.

🚫 NEVER TRUST    ✅ ALWAYS VERIFY    🔒 LEAST PRIVILEGE

👤 Verify Identity Explicitly
📱 Validate Device Health
🌐 Inspect Every Request
🔑 Grant Minimum Access
👁️ Monitor Continuously

1 Zero Trust Principles & Pillars

Zero Trust is not a single product — it is a security philosophy implemented across six technology pillars. NIST SP 800-207 defines the authoritative Zero Trust Architecture framework that this guide follows. Each pillar addresses a different trust assumption that traditional security models make incorrectly.

👤
Identity
Strong MFA, SSO, conditional access policies, and privileged identity management — identity is the new perimeter
💻
Devices
Device health attestation, compliance checking, MDM enrollment, and certificate-based trust before granting access
🌐
Network
Micro-segmentation, software-defined perimeter, encrypted traffic inspection, and elimination of implicit network trust
📦
Applications
Application-layer access control, ZTNA replacing VPN, per-application authentication, and API security
🗄️
Data
Data classification, encryption at rest and in transit, DLP policies, and access governed by data sensitivity labels
👁️
Visibility
Comprehensive logging, SIEM integration, UEBA behavioral analytics, and continuous threat detection across all pillars

Zero Trust vs Traditional Security

AssumptionTraditional (Castle & Moat)Zero Trust
Network locationInside network = trustedNetwork location is irrelevant — verify all
User identityValid credentials = access grantedCredentials + MFA + context + behavior
Device trustCorporate network = trusted deviceDevice must prove compliance before access
Access scopeVPN = access to entire networkAccess to specific application only
Session validationAuthenticated once = trusted foreverContinuous re-validation throughout session
Lateral movementEasy — flat internal networkPrevented — micro-segmented, no implicit trust

2 Zero Trust Maturity Assessment

The CISA Zero Trust Maturity Model defines five maturity levels across the six pillars — Traditional, Initial, Advanced, and Optimal. Most organizations begin at Traditional or Initial. Understanding your current position across each pillar determines where to invest first.

Self-Assessment — Rate Your Current Posture

Identity
Traditional: Password only Initial: MFA on some apps Advanced: MFA everywhere + SSO Optimal: Risk-adaptive, passwordless
Devices
Traditional: No MDM Initial: MDM enrolled Advanced: Compliance required for access Optimal: Continuous posture, attestation
Network
Traditional: Flat network Initial: Basic VLAN segmentation Advanced: Micro-segmentation + ZTNA Optimal: SDP, encrypted east-west
Applications
Traditional: VPN to all apps Initial: Some app-level auth Advanced: Per-app ZTNA + MFA Optimal: Dynamic policy, inline inspection
Data
Traditional: Unclassified Initial: Manual labeling Advanced: Auto-classify + DLP Optimal: Policy-driven encryption

✅ Start Here: Most organizations should focus on reaching "Advanced" across Identity and Devices first — these two pillars address 80% of real-world breach scenarios. A phishing-resistant MFA deployment combined with device compliance enforcement prevents the most common attack vectors: credential stuffing, phishing, and compromised personal devices. Only after Identity and Devices are at Advanced maturity should you invest heavily in Network micro-segmentation and Application-layer ZTNA.

3 Identity & MFA Foundation

Identity is the cornerstone of Zero Trust — every other control depends on reliably knowing who is making an access request. Deploying strong MFA and centralized identity management is the single highest-impact Zero Trust investment for most organizations.

MFA Method Security Ranking

MFA MethodPhishing ResistantEase of UseRecommendation
FIDO2 / Passkeys (hardware key or biometric)✅ YesHighBest — use for privileged users, admins
Microsoft Authenticator (number matching)✅ Yes (with number match)HighExcellent — deploy for all M365 users
TOTP App (Google/Microsoft Authenticator — code)⚠️ No (real-time phishing)HighGood — better than SMS, not phishing-resistant
SMS OTP❌ No (SIM swap, SS7)HighAcceptable if nothing else available — upgrade ASAP
Email OTP❌ NoHighWeakest MFA — email account compromise bypasses it
Push notification (approve/deny)❌ No (MFA fatigue)Very HighEnable number matching to prevent fatigue attacks

Azure AD Conditional Access — Zero Trust Policies

# Azure AD Conditional Access Policies — configure in: # Entra ID (Azure AD) → Protection → Conditional Access → Policies # ── Policy 1: Require MFA for All Users ──────────────── Name: "ZT-01 Require MFA — All Users All Apps" Users: All users (exclude break-glass emergency accounts) Apps: All cloud apps Conditions: Locations: Any location Grant: ✅ Require multi-factor authentication ✅ Require authentication strength: Phishing-resistant MFA Session: Sign-in frequency: Every 8 hours (re-auth required) # ── Policy 2: Block Legacy Authentication ────────────── Name: "ZT-02 Block Legacy Auth" Users: All users Apps: All cloud apps Conditions: Client apps: Exchange ActiveSync clients, Other clients (legacy) Grant: 🚫 Block access # Why: Legacy auth (SMTP, POP3, IMAP, basic auth) cannot do MFA # This is the #1 way attackers bypass MFA on M365 # ── Policy 3: Require Compliant Device ───────────────── Name: "ZT-03 Require Compliant Device — Sensitive Apps" Users: All users Apps: SharePoint, OneDrive, HR System, ERP Conditions: Platforms: Windows, macOS, iOS, Android Grant: ✅ Require device to be marked as compliant (Intune) ✅ Require MFA Operator: Require ALL selected controls # ── Policy 4: Block High-Risk Sign-ins ───────────────── Name: "ZT-04 Block High Risk Sign-Ins" Users: All users Apps: All cloud apps Conditions: User risk: High Sign-in risk: High (impossible travel, TOR, malware) Grant: 🚫 Block access # Or: Require MFA + require password change (less disruptive)

⚠️ Warning: Before enabling the "Require Compliant Device" Conditional Access policy — ensure ALL devices used for work are enrolled in Microsoft Intune and marked compliant. Enabling this policy before completing Intune enrollment will lock out users on unenrolled devices immediately, including executives and remote workers. Deploy Intune enrollment first, give users 2 weeks to enroll, then enable the policy in Report-Only mode for 1 week to audit scope, then enforce.

4 Device Trust & Posture Validation

In Zero Trust, a valid username and password is not sufficient for access — the device making the request must also prove it meets security requirements. An attacker who steals credentials from a compromised personal device should still be blocked if that device is not compliant with your security baseline.

Microsoft Intune Device Compliance Policies

# Intune Compliance Policy — Windows 10/11 # Intune → Devices → Compliance Policies → Create Policy → Windows 10+ Device Health: Require BitLocker: Require Require Secure Boot: Require Require code integrity: Require Device Properties: Minimum OS version: 10.0.19044 (Windows 10 22H2) Maximum OS version: Leave blank System Security: Require password: Require Minimum password length: 8 Password type: Alphanumeric Maximum minutes of inactivity: 15 minutes Password expiration (days): 90 Number of previous passwords: 5 Firewall: Require Antivirus: Require Antispyware: Require Microsoft Defender Antimalware: Require Defender Antimalware minimum version: 4.18.0.0 Real-time protection: Require Microsoft Defender ATP (EDR): Require machine risk score ≤ Medium Actions for noncompliance: Day 0: Mark device noncompliant Day 3: Send email to user — "Your device is not compliant" Day 7: Retire device (optional — blocks corporate data access) # Assign policy to: All Devices (or specific Entra ID group)

Certificate-Based Device Authentication

# Deploy device certificates via Intune SCEP/PKCS profile # These certificates identify managed devices to internal resources # without requiring user password entry — device identity = certificate # Intune → Devices → Configuration Profiles → Create → SCEP Certificate Profile name: "EnterWeb-Device-Identity-Cert" Platform: Windows 10 and later Certificate type: Device Subject name format: CN={{DeviceId}},O=EnterWeb IT Firm Subject alternative name: DNS: {{DeviceName}}.enterweb.local Certificate validity: 1 year (auto-renewed by Intune) Key size: 2048 Key usage: Digital signature, Key encipherment Extended key usage: Client Authentication (1.3.6.1.5.5.7.3.2) SCEP server URLs: https://[your-ndes-server]/certsrv/mscep/mscep.dll # This certificate is then used by: # - WiFi 802.1X authentication (no password needed for corporate WiFi) # - VPN authentication (certificate + MFA = strong auth) # - ZTNA client authentication (Fortinet FortiClient / Azure AD join)

5 Micro-Segmentation

Micro-segmentation replaces flat, trusted internal networks with isolated segments where even internal traffic requires explicit authorization. It is the primary control that limits lateral movement — preventing an attacker who compromises one system from freely moving to others.

Segmentation Strategy

  1. Map all internal traffic flows: Before segmenting, document which systems talk to which — application servers to databases, clients to file servers, monitoring to all devices. Segmentation without traffic maps causes application outages
  2. Define security zones: Group systems by sensitivity and function — not just by team or department. The key zones are: User endpoints, Servers (web tier, app tier, DB tier), Management (monitoring, jump servers, AD), IoT/OT devices, DMZ (internet-facing), Guest
  3. Apply deny-all between zones by default: No inter-zone traffic unless explicitly permitted by firewall policy — this is the opposite of the current state for most organizations
  4. Implement application-aware policies: Where possible, use application-layer (Layer 7) rules — allow "ERP application traffic from app servers to DB servers" rather than "any TCP from 10.10.2.0/24 to 10.10.3.0/24"
  5. Protect east-west traffic: Deploy internal firewalling between server segments — FortiGate internal segmentation firewall, or VMware NSX for virtualized environments

FortiGate Micro-Segmentation Implementation

# FortiGate — Internal Segmentation Firewall Policies # Assuming VLANs: Users=VLAN10, Servers=VLAN20, DBs=VLAN30, Mgmt=VLAN50 # ── DENY ALL inter-VLAN base policy (lowest priority) ── config firewall policy edit 900 set name "ZT-DENY-ALL-INTERNAL" set srcintf "VLAN10" "VLAN20" "VLAN30" set dstintf "VLAN10" "VLAN20" "VLAN30" set srcaddr "all" set dstaddr "all" set action deny set schedule "always" set logtraffic all # Log ALL denied traffic — feeds SIEM set comments "ZT Baseline — deny all unless explicitly permitted" next end # ── ALLOW: Web servers → App servers (specific ports) ── config firewall policy edit 100 set name "ZT-Web-to-App-HTTPS" set srcintf "VLAN20" set dstintf "VLAN20" set srcaddr "GRP-Web-Servers" # FortiGate address group set dstaddr "GRP-App-Servers" set action accept set schedule "always" set service "HTTPS" "HTTP" set ssl-ssh-profile "certificate-inspection" set logtraffic all set application-list "ZT-App-Control" # App-aware inspection next end # ── ALLOW: App servers → Database (MySQL only) ───────── config firewall policy edit 101 set name "ZT-App-to-DB-MySQL" set srcintf "VLAN20" set dstintf "VLAN30" set srcaddr "GRP-App-Servers" set dstaddr "GRP-DB-Servers" set action accept set schedule "always" set service "MySQL" # Port 3306 only — not "any" set logtraffic all next end # ── BLOCK: Users → Database (direct DB access denied) ── config firewall policy edit 102 set name "ZT-BLOCK-Users-to-DB" set srcintf "VLAN10" set dstintf "VLAN30" set srcaddr "all" set dstaddr "all" set action deny set logtraffic all set comments "Users must access DB only through app tier" next end

✅ Pro Tip: Before enforcing micro-segmentation deny policies — run them in monitor mode (FortiGate: set action accept + logtraffic all) for 2 weeks to capture all actual traffic flows. Export the firewall logs, identify every unique source-destination-port combination, and build allow rules for each legitimate flow. Only then switch the base policy to deny. This prevents the most common micro-segmentation failure mode: blocking legitimate application traffic and causing production outages on Day 1.

6 ZTNA Deployment — FortiGate & Azure

Zero Trust Network Access (ZTNA) replaces traditional VPN with per-application, identity-verified access. Instead of granting users full network access through a VPN tunnel, ZTNA brokers individual application connections — users can only reach the specific applications they are authorized for, nothing else.

ZTNA vs Traditional VPN

FeatureTraditional VPNZTNA
Access scopeFull network access after authSpecific application only
Lateral movement riskHigh — user can reach any internal IPNone — no network-level access
Device verificationNone — any device can connectDevice posture checked before each session
User experienceSlow, requires explicit connectionTransparent, app-specific, faster
Application visibilityNone — encrypted tunnelFull app-layer inspection per session
ScalabilityVPN concentrator bottleneckCloud-distributed, scales elastically

FortiGate ZTNA Configuration

# FortiGate ZTNA — FortiClient EMS Required # Requires: FortiGate 7.x + FortiClient EMS 7.x + FortiClient 7.x on endpoints # Step 1: Configure FortiClient EMS connection (GUI) # Security Fabric → Fabric Connectors → FortiClient EMS # EMS IP: 10.10.50.20 (your EMS server) # Step 2: Create ZTNA Server (defines protected application) config firewall access-proxy edit "ZT-ERP-Access" set vip "ERP-ZTNA-VIP" set client-cert enable # Require device certificate set user-agent-detect enable config api-gateway edit 1 set url-map "/" set service-type https set realservers edit 1 set ip 10.10.2.50 # Internal ERP server IP set port 443 next end next end next end # Step 3: Create ZTNA Firewall Policy config firewall policy edit 200 set name "ZT-ERP-Remote-Access" set srcintf "ssl.root" # ZTNA interface set dstintf "VLAN20" set srcaddr "all" set dstaddr "GRP-ERP-Servers" set action accept set schedule "always" set service "HTTPS" # ZTNA Tags — device must pass these checks: set ztna-status enable set ztna-ems-tag "EMS_ZT-Compliant" # Device is Intune/EMS compliant set ztna-ems-tag "EMS_ZT-AVenabled" # Antivirus running set ztna-ems-tag "EMS_ZT-OSpatched" # OS patched in last 30 days # User authentication via FortiAuthenticator + LDAP + MFA set groups "GRP-ERP-Users" set logtraffic all set utm-status enable set av-profile "ZT-AV-Strict" set ssl-ssh-profile "ZT-Deep-Inspection" next end

Azure AD Application Proxy — ZTNA for On-Premises Apps

# Azure AD Application Proxy — publish on-premises apps securely # No VPN required — users access via browser with Azure AD auth + MFA # Prerequisites: # 1. Install Application Proxy Connector on-premises server # (Windows Server 2019, domain-joined, outbound HTTPS to Azure only) # 2. Connector requires outbound port 443 — no inbound firewall rules # Configure in Azure Portal: # Entra ID → Applications → Enterprise Applications # → New Application → Add an on-premises application Application name: "EnterWeb-Intranet-Portal" Internal URL: http://intranet.enterweb.local External URL: https://intranet-enterweb.msappproxy.net (auto-assigned) Pre-authentication: Azure Active Directory ← Forces MFA before any request reaches server Connector group: Default (or region-specific group) # Assign users: # Enterprise App → Users and Groups → Add user/group # Only assigned users can access — all others blocked at Azure AD level # Add Conditional Access policy for this app: # Conditional Access → New Policy # Cloud apps: "EnterWeb-Intranet-Portal" # Grant: Require MFA + Require compliant device # Result: Remote users go through Azure MFA + device check # before their request ever reaches the on-premises server

7 Least Privilege & PAM

Least privilege means every user, service account, and application has only the minimum permissions required to do their job — and nothing more. Privileged Access Management (PAM) extends this to administrator accounts, which represent the highest-value targets for attackers.

Least Privilege Implementation Steps

  1. Audit existing permissions: Export all role assignments from Active Directory, Azure RBAC, and AWS IAM — identify over-privileged accounts, stale permissions, and accounts with Domain Admin or Global Admin that do not need it
  2. Separate admin and user accounts: Every IT staff member with admin duties must have two accounts — a standard user account for daily work (email, browsing) and a separate privileged account used only for administrative tasks
  3. Implement Just-In-Time (JIT) access: Privileged roles are not permanently assigned — staff request elevated access when needed, it is granted for a defined time window (1–8 hours), then automatically revoked
  4. Deploy PAM solution: Azure PIM (Privileged Identity Management) for cloud roles, CyberArk / BeyondTrust / Delinea for on-premises admin accounts — PAM vaults admin credentials, session-records all privileged activity, and enforces approval workflows
  5. Service account hygiene: Audit all service accounts — remove unnecessary privileges, set strong passwords, enable auditing. Replace static service account passwords with Managed Service Accounts (gMSA) where possible
  6. Review quarterly: Access creep is real — run quarterly access certification campaigns where managers confirm their team members still need every permission assigned

Azure PIM — JIT Admin Access

# Azure Privileged Identity Management (PIM) — Configure JIT for Global Admin # Entra ID → Identity Governance → Privileged Identity Management # Step 1: Make Global Admin "Eligible" (not permanent) # PIM → Azure AD roles → Global Administrator → Assignments # Change from "Active" to "Eligible" for all admin users # (Except 2 break-glass emergency accounts — leave these permanently Active) # Step 2: Configure role settings # PIM → Azure AD roles → Global Administrator → Settings Activation maximum duration: 4 hours Require MFA on activation: Yes Require justification on activation: Yes Require approval: Yes (for Global Admin — designate 2 approvers) On activation notifications: Email to Security team # Step 3: Admin activates when needed (user experience) # PIM → My roles → Eligible assignments → Global Administrator → Activate # Enter reason: "Need to create new user accounts for new joiner batch" # Duration: 2 hours # Approval request sent to designated approvers # Access granted within minutes after approval # Auto-revoked after 2 hours — no manual cleanup needed # Step 4: Monitor PIM activity # PIM → Audit history → export for SIEM ingestion # Alert on: Activation without approval (emergency), unusual activation patterns

🚨 Critical: Before converting all Global Admin accounts to Eligible-only in Azure PIM — create and securely store at least two "break-glass" emergency administrator accounts that remain permanently Active and are not subject to Conditional Access or PIM activation. These accounts should have strong random passwords stored in a physical safe, have MFA with a FIDO2 hardware key stored separately, and have their sign-in activity monitored with immediate alerts. Without break-glass accounts, a PIM misconfiguration or MFA system outage can permanently lock all administrators out of your Azure tenant.

8 Continuous Monitoring & Analytics

Zero Trust is not a one-time configuration — it requires continuous monitoring of identity signals, device health, network traffic, and application behavior to detect anomalies that indicate compromised accounts, insider threats, or policy violations in real time.

Zero Trust Monitoring Stack

Key Zero Trust Metrics to Track

MetricTargetMeasurement
MFA coverage100% of usersEntra ID → Authentication Methods → MFA registration report
Device compliance rate> 95% of managed devicesIntune → Device compliance → Compliance report
Legacy auth block rate0 successful legacy auth sign-insAzure AD Sign-in logs → filter by legacy auth clients
Privileged account activation0 permanently active privileged rolesPIM → Azure AD roles → Active assignments
High-risk sign-in response time< 15 minutes to blockIdentity Protection → Risky sign-ins → Time to remediate
Micro-segmentation coverage> 90% of server-server flows explicitly permittedFortiGate policy hit count analysis

✅ Pro Tip: Run a monthly Zero Trust Score review using Microsoft Secure Score (for M365/Azure environments) and AWS Security Hub score (for AWS). Both platforms give you a percentage score with specific, ranked recommendations — clicking any recommendation shows exactly what to configure to implement it. Dedicate 2 hours per month to implementing the top 3 recommendations — organizations that do this consistently improve their Zero Trust posture by 30–50% within 6 months with minimal effort.

Ready to Implement Zero Trust?

EnterWeb IT Firm designs and deploys Zero Trust architectures for Indian enterprises — identity hardening with Azure AD and MFA, device compliance with Intune, micro-segmentation with FortiGate, and ZTNA deployment replacing legacy VPN infrastructure. We build security that works with your users, not against them.

Related Guides