🚫 Zero Trust
Zero Trust Architecture Reference
NIST SP 800-207 principles, 5-pillar maturity assessment, ZTNA deployment patterns, and regulatory alignment for RBI, SEBI, and DPDP.
NIST SP 800-207 — Zero Trust Architecture Tenets
Zero Trust is not a product — it is a security strategy based on the principle of "never trust, always verify." All resources are treated as if they are internet-facing, regardless of network location.
1
All data sources and computing services are resources
Every device, service, and data store — on-premises, cloud, or remote — is treated as a resource. Network location confers no implicit trust.
2
All communication is secured regardless of network location
Traffic between resources must be authenticated and encrypted. The internal network is not trusted by default.
3
Access to individual enterprise resources is granted per-session
Access rights are evaluated each session based on dynamic policy. Prior access does not guarantee future access.
4
Access to resources is determined by dynamic policy
Policy decisions incorporate identity, device health, location, time, and behaviour signals — not just network location.
5
The enterprise monitors and measures the integrity of owned and associated devices
Devices must meet health standards before being allowed to access resources. Compliance is continuously evaluated.
6
All resource authentication and authorisation is dynamic and strictly enforced
Strong MFA, continuous validation, and least-privilege access are enforced at every access attempt.
7
The enterprise collects as much information as possible about the current state of assets
Rich telemetry — device health, user behaviour, traffic patterns — feeds the policy engine for continuous improvement.
Zero Trust vs Traditional Perimeter Security
| Aspect | Traditional Perimeter | Zero Trust |
|---|---|---|
| Trust model | Trust inside the perimeter — implicit trust for internal traffic | Never trust, always verify — explicit trust required for every request |
| Network location | Internal network = trusted; external = untrusted | Network location is irrelevant — all traffic treated as untrusted |
| Access control | VPN grants broad network access | Least-privilege per-session access to specific resources only |
| Identity | Username/password often sufficient | MFA + device health + behaviour signals required |
| Lateral movement | Easy — attacker inside perimeter can pivot freely | Difficult — every east-west request requires authentication |
| Breach assumption | Assume breach is avoidable | Assume breach is inevitable — limit blast radius |
| Monitoring | Perimeter inspection (firewall logs) | Continuous monitoring of all sessions, devices, and behaviour |
The Five Zero Trust Pillars
Identity
Verify every user and service with MFA and continuous risk scoring
Device
Validate device health, compliance, and posture before granting access
Network
Segment networks, encrypt all traffic, eliminate implicit trust zones
Application
Secure app-level access, API gateways, and workload identity
Data
Classify, label, encrypt, and monitor data at rest and in transit
🪪 Identity
Authenticate every user, device, and workload. Use MFA, phishing-resistant authentication (FIDO2/passkeys), and continuous risk-based access evaluation. Eliminate shared accounts and standing privileged access.
Microsoft Entra ID / Azure AD Conditional AccessOkta Adaptive MFACrowdStrike Falcon Identity ProtectionBeyondTrust Privileged Access ManagementFIDO2 hardware keys (YubiKey, Titan)
💻 Device
Verify device posture before granting access. Devices must be managed, patched, and compliant with organisational policy. Bring-your-own-device requires device health checks and separate access policies.
Microsoft Intune (MDM/MAM)CrowdStrike Falcon Device ControlJamf (macOS/iOS)Google Chrome EnterpriseIvanti Neurons for MDM
🌐 Network
Replace VPN with ZTNA. Segment networks microscopically — each workload in its own segment with firewall rules for required flows only. Encrypt all east-west traffic, not just perimeter.
Zscaler Private Access (ZPA)Cloudflare AccessPalo Alto Prisma AccessCisco Duo ZTNAGoogle BeyondCorp Enterprise
📱 Application
Enforce least-privilege access at the application layer. Use API gateways with authentication for all APIs. Implement workload identity for service-to-service calls. Protect admin interfaces behind identity-aware proxies.
Apigee / Kong API GatewayHashiCorp Vault (workload identity)Cloudflare Access for AppsAWS Verified AccessGoogle Identity-Aware Proxy
💾 Data
Classify all data by sensitivity. Apply encryption at rest and in transit. Monitor data access and flag anomalies. Enforce data loss prevention (DLP) at egress points. Apply retention policies aligned to regulatory requirements.
Microsoft Purview (data classification + DLP)Varonis Data Security PlatformForcepoint DLPAWS Macie (S3 data classification)Google Cloud DLP
Zero Trust Maturity Assessment
Rate your current Zero Trust maturity across each pillar. 1 = Traditional (no ZT), 5 = Optimal (fully automated, adaptive ZT).
Identity
2/5
Device
2/5
Network
2/5
Application
2/5
Data
2/5
Visibility & Analytics
2/5
Automation & Orchestration
2/5
Overall Maturity: Developing
Focus on Identity and Device pillars first — they deliver the highest risk reduction for ZT investment.
Maturity Levels Explained
| Level | Name | What it means |
|---|---|---|
| 1 | Traditional | Implicit trust on internal network. Perimeter-based security. VPN for remote access. No per-session access control. |
| 2 | Initial | Identity-based access beginning. MFA deployed for some users. MDM for some devices. Basic network segmentation. |
| 3 | Advanced | MFA enforced for all users. Device compliance checked. ZTNA replacing VPN. Per-application access policies. |
| 4 | Optimal | Continuous risk scoring. Behaviour-based access decisions. Micro-segmentation deployed. Data classification and DLP active. |
| 5 | Cutting-Edge | Fully automated policy adjustment. ML-driven anomaly detection. Real-time revocation. Passwordless everywhere. |
ZTNA Deployment Patterns
| Pattern | How it works | Best for | Key products |
|---|---|---|---|
| Agent-based ZTNA | A lightweight agent on the device enforces access policy and routes traffic through a cloud proxy. Device posture checked before each session. | Managed devices, enterprise workforce, remote access replacement for VPN. | Zscaler ZPA, Palo Alto Prisma, Cloudflare WARP+Access |
| Agentless ZTNA (Browser-based) | Access via browser — no agent required. Identity checked at login; traffic flows through a reverse proxy. | BYOD, contractors, third-party access, unmanaged devices. | Cloudflare Access, Google IAP, Microsoft Entra App Proxy |
| Identity-Aware Proxy (IAP) | Proxy sits in front of internal applications. Authentication and authorisation evaluated per request. Application never directly exposed. | Internal web apps, admin tools, developer access to staging environments. | Google BeyondCorp, Cloudflare Access, AWS Verified Access |
| Service Mesh (workload ZT) | mTLS enforced for every service-to-service call. Workload identity (SPIFFE/SPIRE) rather than network location. | Microservices, Kubernetes, containerised workloads. | Istio, Linkerd, Consul Connect, AWS App Mesh |
| Micro-segmentation | Software-defined network segments with per-workload firewall rules. East-west traffic explicitly allowed or denied. | Data centres, private cloud, hybrid cloud — lateral movement prevention. | Illumio, Guardicore, VMware NSX, AWS Security Groups |
Zero Trust & India Regulatory Alignment
| Regulation | ZT Principle Alignment | Specific Requirements | ZT Control |
|---|---|---|---|
| RBI IT Framework | Least privilege, access control, privileged access management | Restrict admin access, separate prod/dev environments, MFA for remote admin | Identity Pillar — PAM, MFA, per-session least privilege |
| RBI CSCRF | Network segmentation, continuous monitoring, access control | Segment SWIFT, CBS, and payment systems from general networks | Network Pillar — micro-segmentation of critical financial systems |
| SEBI CSCRF 2024 | Zero trust principles explicitly referenced in 2024 framework | Least privilege access, continuous verification, behaviour monitoring | All 5 pillars — SEBI is the most explicit India regulation endorsing ZT |
| CERT-In Directions 2022 | NTP sync, 180-day log retention, 6-hour incident reporting | Full audit logging of all access events, user activity monitoring | Visibility Pillar — centralised logging, SIEM integration |
| DPDP Act 2023 | Data minimisation, purpose limitation, data security safeguards | Classify personal data, limit access to minimum necessary, encrypt all PD | Data Pillar — classification, access controls, encryption |
| IRDAI ISRM 2023 | Privileged access management, network segmentation, monitoring | PAM solution, network micro-segmentation, behaviour analytics | Identity + Network Pillars |
ZT Implementation Priorities for India BFSI
→
Priority 1 — MFA on all privileged access
RBI IT Framework and SEBI CSCRF both mandate MFA for admin and remote access. Deploy phishing-resistant MFA (FIDO2) for all privileged accounts. CERT-In breach statistics consistently show credential compromise as the leading attack vector.
→
Priority 2 — Segment SWIFT and CBS
Payment system compromise is the highest-value attack for India-targeting threat actors (including Lazarus Group). Micro-segment SWIFT, CBS, and RTGS systems from the general enterprise network. No lateral movement path from workstation to payment infrastructure.
→
Priority 3 — DPDP-compliant data classification
DPDP Act 2023 requires data fiduciaries to implement appropriate technical safeguards. Data classification underpins both the Data pillar of ZT and DPDP compliance. Label all personal data, enforce access based on classification, log all access events.
→
Priority 4 — Replace VPN with ZTNA for remote access
VPN grants broad network access — dangerous when credentials are compromised. ZTNA provides application-level access only. Multiple India BFSI breaches have used compromised VPN credentials to achieve initial access.