Traditional network security was built on a simple assumption: trust everything inside the corporate perimeter, block everything outside it. That assumption collapsed the moment corporate data moved to the cloud, employees started working from home, and contractors began accessing internal systems from personal devices. The perimeter-based model does not work when there is no perimeter.<\/p>\n\n\n\n
Zero Trust replaces that assumption with a different one: trust nothing by default, verify everything explicitly, and enforce least privilege access at every layer. In Microsoft’s ecosystem, the implementation of Zero Trust runs through Microsoft Entra ID \u2014 the identity platform that underpins Microsoft 365<\/a>, Azure<\/a>, and every access decision in between.<\/p>\n\n\n\n This guide covers the full Entra ID and Zero Trust architecture stack for Indian enterprises: Conditional Access design, Privileged Identity Management, identity lifecycle governance, Microsoft Intune endpoint management, and how each layer maps onto the DPDP Act’s requirements for reasonable security safeguards. It is written for IT admins and security leads who want to move from a basic M365 deployment to a genuinely hardened, Zero Trust identity architecture.<\/p>\n\n\n\n Licence note: <\/strong>Several features in this guide require Microsoft Entra ID P1 (included in M365 Business Premium and E3) or Entra ID P2 (included in M365 E5). The licence requirement is noted in each section. Microsoft’s new M365 E7 tier (launching May 2026 at approximately \u20b98,250\/user\/month) bundles the full Entra Suite, Copilot, and E5 security \u2014 relevant context for Indian enterprises approaching EA renewal.<\/p>\n\n\n\n Zero Trust is defined by three principles. Understanding what each one means operationally \u2014 not just conceptually \u2014 is the prerequisite for designing any implementation.<\/p>\n\n\n\n Every access request must be authenticated and authorised based on all available data points \u2014 identity, location, device health, service or workload, data classification, and anomaly detection. The fact that a user is inside the corporate network, connected to the VPN, or has authenticated once today is not sufficient. Each resource access is evaluated independently.<\/p>\n\n\n\n Zero Trust principle: <\/strong>In Microsoft 365, Verify Explicitly is implemented through Conditional Access policies that evaluate real-time signals \u2014 sign-in risk, device compliance, location, and MFA status \u2014 before granting access to each resource.<\/p>\n\n\n\n Users, services, and devices should have only the minimum access required to perform their function, for only as long as they need it. This applies to user accounts (no standing Global Admin access), service accounts (scoped API permissions rather than blanket admin roles), and external identities (time-limited guest access rather than permanent membership).<\/p>\n\n\n\n Zero Trust principle: <\/strong>Least privilege in M365 is implemented through role-based access control in Entra ID, Privileged Identity Management for just-in-time privileged access, and access reviews that revoke permissions that are no longer needed.<\/p>\n\n\n\n Design your architecture as if an attacker has already gained a foothold \u2014 because in a statistically significant proportion of enterprise environments, they have. This means limiting blast radius through network segmentation, ensuring all activity is logged and monitored, and designing for detection and response rather than just prevention.<\/p>\n\n\n\n Zero Trust principle: <\/strong>Assume Breach in M365 is implemented through Microsoft Defender for Identity and Defender for Office 365 (threat detection), Microsoft Sentinel or Defender XDR (SIEM and response), and unified audit logging in Microsoft Purview (forensic trail).<\/p>\n\n\n\n \ud83c\uddee\ud83c\uddf3 India Context: <\/strong>Indian enterprises are disproportionately targeted by credential-based attacks \u2014 phishing, password spraying, and business email compromise. Microsoft’s 2025 Digital Defense Report noted that Indian organisations experienced a 40% increase in identity-based attacks year-over-year. Zero Trust architecture, specifically the Verify Explicitly principle implemented through Conditional Access and MFA, is the most effective defence against these attacks. An organisation that has enforced MFA through Conditional Access eliminates over 99% of credential-based account compromises.<\/em><\/p>\n\n\n\n Conditional Access is the heart of Zero Trust in Microsoft 365. It is the policy engine that evaluates every access request against a set of conditions and grants, blocks, or challenges access based on the result. Getting Conditional Access design right is the single highest-leverage security investment an Indian enterprise can make in its Microsoft 365 environment.<\/p>\n\n\n\n Conditional Access is available with Entra ID P1 (M365 Business Premium, E3, and above).<\/p>\n\n\n\n Conditional Access works in three stages. First, it collects signals: who is the user, what role do they have, what device are they on, is the device compliant, what is their sign-in risk score, what location are they accessing from, what application are they trying to reach? Second, it evaluates these signals against your policies. Third, it enforces the decision \u2014 grant access, block access, grant access with conditions (require MFA, require compliant device, require password change).<\/p>\n\n\n\n Do not start with a single monolithic policy. Build a stack of targeted policies, each addressing a specific risk scenario. A well-designed CA policy stack for an Indian enterprise covers these scenarios as a minimum:<\/p>\n\n\n\n \ud83c\uddee\ud83c\uddf3 India Context: <\/strong>Indian enterprises with hybrid work patterns \u2014 employees in offices, at home, at client sites, and traveling domestically \u2014 need named location policies that are flexible enough to not constantly block legitimate access while being strict enough to catch genuine anomalies. A practical approach: require MFA for all locations (non-negotiable), require compliant device for sensitive applications (apply to all locations), and reserve IP-based restrictions for admin console access only. This provides strong security without creating a productivity burden for highly mobile teams.<\/em><\/p>\n\n\n\n Entra ID Protection (formerly Azure AD Identity Protection) is a machine learning-powered risk detection engine that analyses every sign-in and user behaviour across Microsoft’s global threat intelligence network. It assigns risk scores to sign-ins and users, which Conditional Access policies can use to make real-time access decisions.<\/p>\n\n\n\n Entra ID Protection is available with Entra ID P2 (M365 E5 and above).<\/p>\n\n\n\n Sign-in risk <\/strong>is the probability that a specific sign-in was not performed by the account owner. High sign-in risk signals include: atypical travel (sign-in from Mumbai 2 hours after a sign-in from Bangalore \u2014 physically impossible), sign-in from anonymous IP (Tor exit nodes, known proxy services), malware-linked IP addresses, and unfamiliar sign-in properties (new device, new location, new browser).<\/p>\n\n\n\n User risk <\/strong>is the probability that a user account itself has been compromised \u2014 based on leaked credential intelligence (Microsoft monitors the dark web for credential dumps), unusual account activity patterns, and aggregated sign-in risk events over time.<\/p>\n\n\n\n \ud83c\uddee\ud83c\uddf3 India Context: <\/strong>Entra ID Protection’s leaked credential detection is particularly relevant for Indian enterprises where employees frequently reuse passwords across personal and corporate accounts. When a credential dump surfaces on the dark web containing an employee’s work email and password, Entra ID Protection flags the account as High user risk before the attacker has had a chance to use it. This is one of the most underutilised security capabilities in the Microsoft E5 stack \u2014 and it requires no configuration beyond enabling the risk policies.<\/em><\/p>\n\n\n\n Privileged Identity Management (PIM) is the feature that eliminates the single biggest identity risk in most Microsoft 365 tenants: administrators who have Global Admin or other high-privilege roles assigned permanently, 24 hours a day, 7 days a week \u2014 whether they are using those privileges or not.<\/p>\n\n\n\n A permanently assigned Global Admin account is a standing high-value target. If that account is compromised \u2014 via phishing, credential stuffing, or session token theft \u2014 the attacker has immediate, unrestricted access to everything in the tenant. PIM replaces permanent role assignment with just-in-time (JIT) access: an admin must request elevation to a privileged role, provide a justification, potentially receive approval, and is granted the role for a defined time window (typically 1\u20138 hours) after which it expires automatically.<\/p>\n\n\n\n PIM is available with Entra ID P2 (M365 E5 and above).<\/p>\n\n\n\n Eligible assignment <\/strong>(the PIM model): The user is eligible for the role but does not hold it. When they need elevated access, they activate the role in PIM, provide a justification, potentially receive manager or IT approval, and are granted the role for a limited time. This is the correct model for all privileged roles.<\/p>\n\n\n\n Active assignment <\/strong>(the traditional model): The user permanently holds the role. This should be reserved only for break-glass emergency accounts that cannot go through a PIM activation process.<\/p>\n\n\n\n Admin path: <\/strong>Entra Admin Centre \u2192 Identity Governance \u2192 Privileged Identity Management \u2192 Microsoft Entra roles \u2192 Roles.<\/em><\/p>\n\n\n\n \u26a0 Watch out: <\/strong>PIM activation requires Entra ID P2. If you are on M365 E3, PIM is not included. Consider adding the Entra ID P2 licence for your IT admin and security team accounts specifically \u2014 you do not need P2 for all users, only for users who will hold or request privileged roles.<\/em><\/p>\n\n\n\n \ud83c\uddee\ud83c\uddf3 India Context: <\/strong>Indian enterprises where multiple IT team members share credentials (a common practice in environments that have grown organically without formal governance) must address this before implementing PIM. PIM’s audit trail and justification requirements only work when each admin has an individual account. Shared credentials make it impossible to attribute actions to a specific individual \u2014 a significant compliance gap under both the DPDP Act (which requires accountability for personal data access) and any internal audit framework.<\/em><\/p>\n\n\n\n The identity lifecycle \u2014 provisioning accounts when people join, updating them when people move between roles, and deprovisioning them when people leave \u2014 is the operational foundation of Zero Trust. No Conditional Access policy or PIM configuration compensates for accounts that exist beyond their purpose or that carry permissions from a previous role.<\/p>\n\n\n\n Identity lifecycle governance in Entra ID spans three capabilities: HR-driven provisioning, access packages, and access reviews. Together they automate the joiner-mover-leaver process and ensure access is continuously right-sized to current role requirements.<\/p>\n\n\n\n Microsoft Entra ID supports automatic user provisioning from HR systems \u2014 SAP SuccessFactors, Workday, and any HRMS with a SCIM-compatible API. When an employee is added to the HR system, their Entra ID account is created automatically, assigned to the correct group and licence, and given the appropriate access package. When they leave, their account is automatically disabled and deprovisioned.<\/p>\n\n\n\n Access packages (part of Entra ID Governance, available with Entra ID P2) are bundles of resources \u2014 group memberships, application access, SharePoint site access \u2014 that can be requested by users and approved by managers, with time-limited access and automatic expiry.<\/p>\n\n\n\n Access reviews are periodic automated checks that ask managers or resource owners to confirm whether their direct reports still need specific access. They are the mechanism that catches permissions accumulation \u2014 users who have changed roles but retained access from previous positions.<\/p>\n\n\n\n Admin path: <\/strong>Entra Admin Centre \u2192 Identity Governance \u2192 Access reviews \u2192 New access review.<\/em><\/p>\n\n\n\n \ud83c\uddee\ud83c\uddf3 India Context: <\/strong>India’s IT attrition rate of approximately 25% means the mover and leaver processes in the identity lifecycle are high-frequency events in most Indian enterprises. An employee who changes roles from Sales to Product carries Sales group membership, CRM access, and Sales Shared Drive access into their new role if no mover process triggers access removal. Six months later, they have access to two departments’ worth of data with no business justification. Quarterly access reviews are the scalable solution \u2014 they catch this accumulation systematically across the entire organisation.<\/em><\/p>\n\n\n\n Zero Trust’s Verify Explicitly principle requires that device health is a real-time input to every access decision. If you cannot verify that a device is enrolled, encrypted, running current OS patches, and free of detected malware, you cannot make a trustworthy access decision based on device compliance. Microsoft Intune is the device management platform that generates the device health signals that Conditional Access policies consume.<\/p>\n\n\n\n Intune is included in M365 Business Premium, E3, and E5.<\/p>\n\n\n\n Device enrolment in Intune can follow several models depending on whether devices are corporate-owned or personal (BYOD).<\/p>\n\n\n\n Compliance policies define what ‘compliant’ means for each device type. A device that meets the compliance policy criteria generates a compliant status in Entra ID that Conditional Access policies can require for access to sensitive applications.<\/p>\n\n\n\n Admin path: <\/strong>Intune Admin Centre (endpoint.microsoft.com) \u2192 Devices \u2192 Compliance policies \u2192 Create policy. Select platform \u2192 configure requirements \u2192 assign to All Devices or specific groups.<\/em><\/p>\n\n\n\n Configuration profiles push security settings to enrolled devices \u2014 enforcing settings that users cannot change, regardless of their preferences.<\/p>\n\n\n\n \ud83c\uddee\ud83c\uddf3 India Context: <\/strong>Indian enterprises managing a mix of corporate devices and personal BYOD devices face a practical challenge: enforcing Intune enrolment for BYOD will encounter user resistance, particularly from senior employees and contractors who do not want IT management on their personal phones. The Android Work Profile and iOS MAM (App Protection Policy) models solve this \u2014 they give IT the control it needs (selective wipe, copy\/paste restrictions, data isolation) without giving IT visibility into personal apps, photos, or data. Communicating this distinction to users before rolling out BYOD management significantly reduces resistance.<\/em><\/p>\n\n\n\n The Digital Personal Data Protection Act creates security requirements that map directly onto the Zero Trust architecture components in this guide. This section maps each DPDP obligation to the specific Entra ID and M365 control that addresses it.<\/p>\n\n\n\n The DPDP Act requires Data Fiduciaries to implement reasonable security safeguards to prevent personal data breaches. The following controls together constitute a defensible ‘reasonable safeguards’ posture for personal data processed in Microsoft 365:<\/p>\n\n\n\n The DPDP Act is expected to require notification to the Data Protection Board within 72 hours of becoming aware of a personal data breach. Your Zero Trust architecture should support breach detection, containment, and notification within this window.<\/p>\n\n\n\n Zero Trust is not a project \u2014 it is a maturity progression. The following phased roadmap structures the implementation in order of impact and prerequisite dependencies.<\/p>\n\n\n\n PHASE 1 \u2014 IDENTITY BASELINE (MONTH 1)<\/strong><\/p>\n\n\n\n PHASE 2 \u2014 DEVICE TRUST (MONTH 2\u20133)<\/strong><\/p>\n\n\n\n PHASE 3 \u2014 IDENTITY GOVERNANCE (MONTH 3\u20134)<\/strong><\/p>\n\n\n\n PHASE 4 \u2014 CONTINUOUS IMPROVEMENT (ONGOING)<\/strong><\/p>\n\n\n\n The shift to Zero Trust is fundamentally a shift in how you think about trust. The old model trusted the network \u2014 anyone inside the firewall was assumed safe. The new model trusts the identity \u2014 but only after continuously verifying it against device health, location, behaviour, and risk signals.<\/p>\n\n\n\n Microsoft Entra ID, Conditional Access, PIM, Identity Protection, Intune, and identity governance are the components of that new trust model. None of them is individually sufficient. A Conditional Access policy that requires MFA but does not check device compliance can still be satisfied by an attacker using a compromised credential from a malware-infected unmanaged device. The architecture works when the components work together \u2014 each layer reducing the attack surface that the previous layer does not fully close.<\/p>\n\n\n\n For Indian enterprises, the urgency of this architecture is compounded by three factors that are specific to the Indian context: the country’s elevated identity attack surface, the DPDP Act’s explicit requirement for reasonable security safeguards, and the hybrid-work patterns that make network-based perimeter security particularly ineffective. An identity that can be stolen from anywhere must be protected by controls that work everywhere.<\/p>\n\n\n\n The implementation roadmap in this guide structures the work into four phases. Phase 1 \u2014 identity baseline \u2014 can be completed in 30 days and closes the majority of the risk. Each subsequent phase adds depth rather than correcting fundamentals. Start with Phase 1 this week. The question is not whether your organisation will face an identity-based attack \u2014 the data makes clear that it will. The question is whether your architecture is ready for it when it comes.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Traditional network security was built on a simple assumption: trust everything inside the corporate perimeter, block everything outside it. That assumption collapsed the moment corporate data moved to the cloud,…<\/p>\n","protected":false},"author":1,"featured_media":793,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[123,93],"tags":[],"class_list":["post-792","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-microsoft-cloud","category-office-365"],"_links":{"self":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts\/792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/comments?post=792"}],"version-history":[{"count":1,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts\/792\/revisions"}],"predecessor-version":[{"id":794,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts\/792\/revisions\/794"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/media\/793"}],"wp:attachment":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/media?parent=792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/categories?post=792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/tags?post=792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}1. Zero Trust Foundations: The Three Principles in Practice<\/h2>\n\n\n\n
Verify Explicitly<\/h3>\n\n\n\n
Use Least Privilege Access<\/h3>\n\n\n\n
Assume Breach<\/h3>\n\n\n\n
2. Conditional Access: Designing the Policy Engine<\/h2>\n\n\n\n
The Signal-Decision-Enforcement Model<\/h3>\n\n\n\n
Building a Conditional Access Policy Stack<\/h3>\n\n\n\n
\n
Policy Design Best Practices<\/h3>\n\n\n\n
\n
3. Entra ID Protection: Risk-Based Access Decisions<\/h2>\n\n\n\n
Sign-In Risk vs. User Risk<\/h3>\n\n\n\n
Configuring Risk-Based Conditional Access<\/h3>\n\n\n\n
\n
4. Privileged Identity Management: Eliminating Standing Privileged Access<\/h2>\n\n\n\n
Role Assignment Models in PIM<\/h3>\n\n\n\n
Implementing PIM for Microsoft 365<\/h3>\n\n\n\n
\n
5. Identity Lifecycle Governance: Joiners, Movers, and Leavers<\/h2>\n\n\n\n
HR-Driven Provisioning<\/h3>\n\n\n\n
\n
Access Packages<\/h3>\n\n\n\n
\n
Access Reviews<\/h3>\n\n\n\n
\n
6. Microsoft Intune: Zero Trust Endpoint Management<\/h2>\n\n\n\n
Enrolment Strategy<\/h3>\n\n\n\n
\n
Compliance Policies<\/h3>\n\n\n\n
\n
Configuration Profiles<\/h3>\n\n\n\n
\n
7. DPDP Act Alignment in Your Zero Trust Architecture<\/h2>\n\n\n\n
Reasonable Security Safeguards \u2014 Section 8(5) DPDP Act<\/h3>\n\n\n\n
\n
Data Breach Notification \u2014 Expected 72-Hour Standard<\/h3>\n\n\n\n
\n
Data Processor Obligations \u2014 Microsoft as Data Processor<\/h3>\n\n\n\n
\n
Implementation Roadmap: Zero Trust Maturity Phases<\/h2>\n\n\n\n
\n
\n
\n
\n
Identity Is the New Perimeter<\/h2>\n\n\n\n