Zero Trust replaces the perimeter security model with continuous, explicit verification of every access request. NIST SP 800-207 defines the seven tenets; this article maps them to cloud implementation patterns relevant to Indian enterprises.
Sign in to mark this article as read and track your progress.
The traditional network security model drew a hard boundary — the perimeter — around the organisation's assets. Everything inside was trusted; everything outside was untrusted. This model was coherent when employees sat in offices connected to a fixed corporate network.
Cloud migration, remote work, and SaaS adoption have dissolved the perimeter. An employee accessing Salesforce from home over a personal device has no clear "inside" or "outside." Granting network access is no longer sufficient proof that the user, device, or application should be trusted.
The 2020 SolarWinds supply chain attack — where trusted software updates delivered malware to 18,000 organisations including US federal agencies — demonstrated that implicit trust of even internal network peers is dangerous.
Zero Trust Architecture (ZTA) is defined in NIST SP 800-207 (2020) as a security model built on the principle that no user, device, or network segment is inherently trusted. Every access request — whether from inside or outside the corporate network — must be authenticated, authorised, and continuously validated before access is granted.
Google's BeyondCorp programme (2014–2020) was the first large-scale enterprise implementation. Google eliminated the concept of the "trusted corporate network" and moved to a model where every employee authenticates via identity and device health regardless of whether they are in a Google office.
| Tenet | Statement | Cloud Implementation |
|---|---|---|
| 1 | All data sources and computing services are resources | Every cloud service — S3, RDS, Lambda, APIs — is a resource requiring explicit authorisation |
| 2 | All communication is secured regardless of network location | Enforce TLS 1.2+ on all service-to-service calls; use mutual TLS (mTLS) in microservices |
| 3 | Access to resources is granted on a per-session basis | Use short-lived credentials (STS tokens); avoid long-lived access keys |
| 4 | Access is determined by dynamic policy | IAM conditions on IP, MFA, time; ABAC over RBAC |
| 5 | All owned and associated devices are monitored for posture | Integrate device management (MDM) with identity provider; check OS patch level at login |
| 6 | All authentication and authorisation is dynamic and strictly enforced | Re-evaluate access when risk signals change (new location, anomalous behaviour) |
| 7 | Collect security posture data and use it to improve | Feed GuardDuty/Sentinel alerts into SIEM; iterate on policies |
1. Identity Every human and non-human identity (service accounts, CI/CD pipelines, Lambda functions) must have a unique identity, authenticated via strong credentials (MFA for humans, X.509/short-lived tokens for machines). Identity is the new perimeter.
2. Device Access decisions should consider device health. Is the device managed? Is its OS patched? Does it have endpoint protection? AWS IAM supports condition keys on device trust; Azure Conditional Access provides device compliance checks.
3. Network Replace flat networks with microsegmentation. In AWS, each workload tier (web, application, database) occupies separate subnets with Security Groups restricting east-west traffic to specific ports and sources. Transit between segments requires explicit allow rules.
4. Application / Workload Apply least privilege at the application layer. APIs require authentication (OAuth 2.0, API keys). Internal microservices use service mesh (Istio, AWS App Mesh) with mTLS between pods. No service calls another without authentication.
5. Data Classify data and apply controls proportional to sensitivity. Encrypt data at rest and in transit. Log all access to sensitive data. For DPDP Act 2023, ensure personal data can be located, audited, and erased on request.
| Dimension | VPN (Perimeter Model) | Zero Trust |
|---|---|---|
| Trust basis | Network location (inside = trusted) | Identity + device + context |
| Access scope | Full network access after authentication | Least-privilege per-resource access |
| Lateral movement risk | High — one compromised host can pivot | Low — each segment requires new authentication |
| Remote access UX | Tunnel adds latency | Proxied access adds minimal latency |
| Scalability | VPN concentrator bottleneck | Cloud-scale identity plane |
NCIIPC (National Critical Information Infrastructure Protection Centre) released guidance in 2022 recommending ZTA adoption for critical sector organisations. CERT-In Directions 2022 effectively mandate continuous monitoring and rapid incident response — which ZTA's dynamic policy evaluation and pervasive logging naturally enable.
Key implementation note for Indian organisations: the identity provider (IdP) and policy decision point (PDP) are the crown jewels of a ZTA implementation. If the IdP (Azure Entra ID, Okta, AWS IAM Identity Center) is compromised, all access decisions are compromised. These components require the highest level of protection — privileged access management, break-glass procedures, and immutable audit logs stored separately.
