Microsoft 365 is the productivity backbone of most Indian enterprises. Email, Teams, SharePoint, OneDrive, identity — it runs the business. Which makes the gap between how it is configured and how it should be configured a significant, ongoing risk.
The mistakes in this post are not hypothetical. They surface consistently across Indian enterprise Microsoft 365 environments — from 100-seat SMBs to 10,000-seat corporates. Some are security misconfigurations that make headlines when they result in breaches. Some are compliance gaps that will become enforcement findings as the DPDP Act moves into its execution phase. Some are cost inefficiencies that quietly compound across every renewal cycle.
Each mistake includes a specific fix — not general guidance, but the exact admin centre path, policy setting, or process change that addresses it.
Admin access required: Most fixes require Global Administrator or a scoped delegated admin role in the Microsoft 365 Admin Centre (admin.microsoft.com) or Microsoft Entra Admin Centre (entra.microsoft.com). Test Conditional Access and policy changes in Report-Only mode before full enforcement.
Identity and Access Misconfigurations
Mistake #1: Conditional Access Not Configured — or Configured in Report-Only and Never Enforced
Risk: High — Security, Identity, DPDP Act
Conditional Access is the policy engine that controls who can access Microsoft 365 resources, from where, on what devices, and under what conditions. It is the most powerful security control available in Microsoft Entra ID — and it is not enabled by default. In most Indian enterprise Microsoft 365 deployments, it is either absent entirely or configured in Report-Only mode at deployment and never moved to enforcement.
Report-Only mode is valuable for testing the impact of a policy before enforcing it. It becomes a risk when it is left in place permanently because no one had the confidence or time to complete the rollout. Meanwhile, the organisation has no guarantee that sign-ins from unmanaged devices, unknown locations, or risky users are being blocked or challenged.
The most basic Conditional Access baseline — requiring MFA for all users, blocking legacy authentication protocols, and requiring compliant devices for admin access — eliminates the majority of credential-based attack vectors. According to Microsoft’s own data, MFA blocks over 99% of account compromise attacks. Without Conditional Access enforcing it, MFA adoption depends entirely on user behaviour.
🇮🇳 India Context: India’s DPDP Act requires Data Fiduciaries to implement reasonable security safeguards. An Entra ID environment without enforced Conditional Access — where any user can authenticate from any location on any device without MFA — is increasingly difficult to characterise as meeting this standard, particularly for accounts with access to personal data. CERT-In’s guidelines also explicitly reference MFA as a baseline requirement.
How to fix:
- Start with Microsoft’s Security Defaults if you have no Conditional Access policies at all — they enforce MFA for all users and block legacy authentication with a single toggle (Entra Admin Centre → Properties → Manage Security Defaults).
- For environments on Entra ID P1 (included in M365 E3 / Business Premium), create policies using Microsoft’s built-in templates: Require MFA for all users, Block legacy authentication, and Require MFA for administrators.
- Move Report-Only policies to enforcement on a schedule — start with admin accounts, then privileged roles, then all users. Use the Conditional Access What-If tool to preview impact before switching.
- Block legacy authentication protocols (SMTP AUTH, POP3, IMAP, Basic Auth) — these bypass MFA entirely and are the primary vector for credential stuffing attacks against M365 tenants.
Mistake #2: Too Many Global Administrators — and No Privileged Identity Management
Risk: High — Security, Governance
Global Administrator is the highest privilege role in Microsoft 365 — full control over the entire tenant, all users, all settings, all data. In most Indian enterprise deployments, Global Admin is assigned generously: the IT manager, the deputy IT manager, the person who set up the tenant, the external consultant who helped with migration, and sometimes a service account that no one remembers creating.
According to research published in 2025, 63% of Microsoft 365 tenants that Microsoft investigated failed the least-privilege assessment, with excess Global Admin assignments being the most common finding. Each unnecessary Global Admin account is a potential compromise point with maximum blast radius.
The compounding risk is that most Indian enterprises have never implemented Privileged Identity Management (PIM) — the feature that makes privileged role assignments just-in-time and requires justification and approval rather than being permanently active. PIM is included in Entra ID P2 (bundled in M365 E5) and significantly reduces the window of exposure for privileged accounts.
How to fix:
- Entra Admin Centre → Roles and Admins → Global Administrator. Review the current assignment list. Target fewer than 5 Global Admins for most enterprises — ideally 2–3 break-glass accounts with hardware MFA, used only for emergencies.
- Replace Global Admin with scoped roles for day-to-day tasks: User Administrator for user management, Exchange Administrator for mailbox management, Security Administrator for security settings. The principle of least privilege applies to admin roles, not just user accounts.
- If on Entra ID P2 or M365 E5, enable Privileged Identity Management for all privileged roles. Configure eligible assignments (not permanent) with approval workflows and time-limited activation for Global Admin and other high-privilege roles.
- Audit service accounts and external consultant accounts. Any account that does not correspond to a current, named internal employee should be reviewed and either removed or converted to a service principal with scoped permissions.
Mistake #3: Legacy Authentication Protocols Still Enabled
Risk: High — Security
Legacy authentication protocols — Basic Auth for Exchange, SMTP AUTH, POP3, IMAP — were designed before MFA existed. They pass credentials in a way that cannot be intercepted by Conditional Access policies, which means that even if you have enforced MFA for all users, an attacker who obtains a user’s password can authenticate via a legacy protocol and bypass MFA entirely.
Microsoft has been deprecating Basic Auth across Exchange Online since 2022, and most tenants have had it disabled for Exchange-native protocols. However, SMTP AUTH — used by on-premise applications, printers, scanners, and legacy line-of-business systems to send email — often remains enabled because migrating these systems is complex and deprioritised. Each SMTP AUTH-enabled mailbox is a credential exposure point.
🇮🇳 India Context: Indian enterprises with hybrid Microsoft 365 deployments — common in BFSI and manufacturing — often have on-premise systems that rely on SMTP AUTH for email notifications, automated reports, and alerts. The temptation is to leave SMTP AUTH broadly enabled rather than migrating each system. The fix — enabling SMTP AUTH only on the specific mailboxes that require it, not at the tenant level — is more granular but significantly reduces exposure.
How to fix:
- Microsoft 365 Admin Centre → Settings → Org Settings → Modern Authentication. Verify Modern Authentication is enabled and Basic Auth is disabled at the tenant level.
- For SMTP AUTH: Admin Centre → Users → Active Users → [User] → Mail → Manage email apps. Disable SMTP AUTH for all users, then re-enable only for specific service accounts that genuinely require it.
- Create a Conditional Access policy to block legacy authentication protocols: Conditions → Client Apps → select Exchange ActiveSync clients and Other clients. Block access for all users. This catches any legacy protocols that are still active.
- Audit your on-premise systems that send email via M365. Migrate to OAuth 2.0 or certificate-based authentication where possible. For systems that cannot be migrated, restrict SMTP AUTH to named service accounts with strong passwords and no interactive sign-in.
Data Protection and Backup Misconceptions
Mistake #4: Believing Microsoft Backs Up Your Microsoft 365 Data
Risk: High — Data Loss, Business Continuity
This is the most persistent and consequential misconception in Microsoft 365 deployments, and it affects enterprises of every size. Microsoft provides infrastructure redundancy and high availability — meaning their datacentres are resilient and the service stays online. Microsoft does not provide backup and recovery for your data in the sense that most IT leaders understand backup.
What this means in practice: if a user permanently deletes a SharePoint site, empties their Recycle Bin, and the 93-day secondary recycle bin retention window passes — that data is gone. If a ransomware attack encrypts files across OneDrive and SharePoint — and synchronises the encrypted versions to Microsoft’s cloud before anyone notices — those encrypted files are what Microsoft has stored. The February 2026 Microsoft 365 outage reinforced this: Microsoft’s SLA covers service availability, not data recovery.
Microsoft 365 retention policies are not a backup. They are designed for compliance and eDiscovery — retaining content for legal and regulatory purposes. They do not provide point-in-time restore, granular file recovery, or protection against accidental deletion by users who are not subject to a retention hold.
🇮🇳 India Context: Under the DPDP Act, personal data loss attributable to inadequate data protection measures is the organisation’s liability — not Microsoft’s. If customer or employee personal data stored in SharePoint or Exchange is lost due to accidental deletion or a ransomware event, and the organisation has no independent backup, the Data Fiduciary bears the regulatory exposure. Microsoft’s shared responsibility model explicitly places data backup in the customer’s responsibility column.
How to fix:
- Implement a third-party Microsoft 365 backup solution that covers Exchange Online, SharePoint, OneDrive, and Teams — for example Veeam Backup for Microsoft 365, Acronis Cyber Protect, or Backupify. These solutions provide point-in-time restore, granular recovery, and protection that Microsoft’s native retention does not.
- Define backup frequency and retention requirements before selecting a solution: how far back do you need to restore? Daily backup with 1-year retention covers most enterprise scenarios.
- Test the restore process quarterly — not just the backup. The ability to restore a deleted SharePoint site, recover a mailbox from 30 days ago, or recover specific Teams conversation history should be verified, not assumed.
- Separate your backup storage from your Microsoft 365 tenant — a ransomware attack that compromises your M365 environment should not also compromise your backup copies.
Mistake #5: SharePoint and OneDrive External Sharing Left Wide Open
Risk: High — Data Exposure, DPDP Act
SharePoint and OneDrive external sharing defaults allow users to share files and folders with anyone — including people outside the organisation and, by default, anyone with the link. This is Microsoft’s default configuration for productivity reasons. For most Indian enterprise environments, it is a security and compliance liability.
The risk accumulates invisibly. A sales team member shares a customer proposal with an external contact using an ‘Anyone’ link. Three years later, that link is still active. The proposal contains customer contact details, pricing information, and internal strategy. Nobody knows this link exists because there is no default expiry, no audit alert, and no admin report that surfaces it without deliberate configuration.
How to fix:
- SharePoint Admin Centre → Policies → Sharing. Set the external sharing level to ‘Existing guests’ or ‘New and existing guests’ — not ‘Anyone’. This requires external recipients to authenticate before accessing shared content.
- Set link expiry for anyone links: if ‘Anyone’ sharing is required for specific use cases, enforce a maximum link expiry of 7–30 days. Admin Centre → SharePoint Admin Centre → Policies → Sharing → Choose expiration time for Anyone links.
- Enable SharePoint audit logs and set up alerts for external sharing events. Microsoft Purview Compliance Portal → Audit → create a search for ‘Sharing invitation created’ and ‘Anonymous link created’ events.
- Run a sharing report to identify files currently shared externally or via ‘Anyone’ links: SharePoint Admin Centre → Reports → Sharing. Review and remediate files with long-lived anonymous links, especially those in HR, Finance, and Legal site collections.
Compliance and Governance Gaps
Mistake #6: Microsoft Purview Unused — No DLP, No Retention, No Audit Policy
Risk: High — DPDP Act, Compliance, Legal
Microsoft Purview (formerly Microsoft Compliance Centre) is the compliance and data governance layer of Microsoft 365. It provides Data Loss Prevention (DLP), retention policies, eDiscovery, audit logging, and sensitive information type detection. It is included in M365 E3 and above. In most Indian enterprise deployments, it is either never configured or configured minimally — a default retention policy and nothing else.
The gap this creates is substantial. Without DLP policies, users can email customer Aadhaar numbers, PAN data, or financial account details to external recipients without any alert or block. Without audit logging configured, there is no record of who accessed what data, when, and from where — removing the forensic trail that DPDP Act incident investigations and CERT-In reporting require. Without retention policies mapped to actual regulatory requirements, data either accumulates indefinitely or is deleted before its legally required retention period expires.
🇮🇳 India Context: The DPDP Act’s requirement for ‘reasonable security safeguards’ explicitly encompasses data minimisation and access logging. Microsoft Purview’s audit logs and DLP policies are the primary tools available in Microsoft 365 to demonstrate compliance with these requirements. An organisation that has Purview available but unconfigured is carrying regulatory risk that its license fees are already paying to mitigate.
How to fix:
- Microsoft Purview Compliance Portal (compliance.microsoft.com) → Audit → Start recording user and admin activity. Enable unified audit logging immediately if it is not already active — this is the foundation of all subsequent compliance and incident response capability.
- Create DLP policies for sensitive data types relevant to India: configure built-in sensitive information types for Aadhaar numbers, PAN numbers, and Indian bank account formats. Start in audit mode to understand the volume of matches before enforcing blocks.
- Define retention policies mapped to your regulatory obligations: 7-year retention for financial records, 3-year for HR records, and data deletion policies for personal data no longer needed for its original purpose under the DPDP Act.
- Configure alert policies for high-risk events: mass email to external recipients, large file downloads from SharePoint, admin role assignment changes, and mailbox access by non-owners.
Mistake #7: Deploying Microsoft 365 Copilot Without a Data Governance Baseline
Risk: High — DPDP Act, Data Exposure, Governance
Microsoft 365 Copilot is now available across Business and Enterprise plans, and many Indian enterprises have enabled it — sometimes at the request of leadership, sometimes as part of a Microsoft EA negotiation — without pausing to assess the data governance implications. Copilot in Microsoft 365 works by accessing the content a user has permission to view: their emails, their Teams messages, files in SharePoint and OneDrive they can access. It surfaces this content to answer questions, summarise meetings, and draft responses.
This creates two risks that most Indian enterprises have not addressed. First, Copilot respects Microsoft 365 permissions — but most Indian enterprise M365 environments have overpermissioned SharePoint sites, broad security group memberships, and files shared more widely than intended. If a user has inadvertent access to a sensitive HR document or financial record, Copilot can surface that content in response to a natural language query. Second, Copilot’s AI-processed content represents personal data processing under the DPDP Act — employees using Copilot to summarise emails containing customer personal data are triggering processing obligations that most organisations have not documented or disclosed.
Microsoft 365 Copilot pricing in India is approximately ₹2,500–3,000 per user per month (excluding GST) as of 2026. At that price point, deploying it to 200 users without a governance framework in place is a ₹60–72 lakh annual commitment with unresolved compliance exposure.
🇮🇳 India Context: Microsoft’s Data Processing Amendment, which should be accepted in the M365 Admin Centre under Billing → Your Products → Microsoft 365 → Data Protection, formalises Microsoft’s role as a Data Processor under DPDP for all M365 services including Copilot. Most Indian enterprises have not accepted this explicitly. For Copilot specifically, Microsoft confirms that Enterprise customer data is not used to train foundation models — but this must be verified in the applicable terms, not assumed.
How to fix:
- Before deploying Copilot broadly, run a SharePoint permissions audit — identify sites, libraries, and files that are accessible to more users than intended. Copilot will surface overpermissioned content. Fix the permissions problem before enabling the AI layer.
- Enable Copilot per user group rather than tenant-wide: M365 Admin Centre → Copilot → Settings → User access. Start with IT and a pilot group, evaluate data exposure, then expand.
- Configure Microsoft Purview’s AI Hub (available in E5 Compliance or as an add-on) to monitor Copilot interactions for sensitive data exposure. At minimum, enable Copilot audit logs in Purview.
- Update your organisation’s privacy notice to disclose AI-assisted processing via Microsoft 365 Copilot. Document the legal basis for processing employee and customer data through Copilot under the DPDP Act.
- Accept Microsoft’s Data Processing Amendment in the Admin Centre if you have not done so — this is a contractual requirement for DPDP compliance, not optional.
Licensing and Cost Inefficiencies
Mistake #8: Paying for E5 Licences Whose Security Features Are Never Used
Risk: Medium — Cost
Microsoft 365 E5 is the premium enterprise tier — it includes advanced threat protection (Defender for Endpoint P2, Defender for Office 365 P2), full Purview compliance capabilities, Entra ID P2 with PIM, and Microsoft Sentinel integration. In India, E5 is priced approximately 40–50% above E3.
Research published in 2025 found that 38% of E5 licences in enterprise environments are oversized — assigned to users based on role seniority or blanket policy rather than actual feature usage. An E5 user who is not actively using Defender for Endpoint’s advanced hunting, eDiscovery, or PIM is paying a significant premium for unused features.
The reverse is equally common: organisations on E3 that have genuine security and compliance requirements — BFSI entities needing eDiscovery, healthcare organisations needing advanced data protection — but are operating without E5 features because no one mapped their regulatory requirements to licence tiers.
🇮🇳 India Context: Microsoft is introducing price increases from July 2026 across several M365 plans. E3 moves from approximately ₹1,400 to ₹1,550 per user per month; E5 increases proportionally. At renewal, Indian enterprises should conduct a licence audit before the new pricing takes effect — the savings from rightsizing to the correct tier, combined with locking in current pricing for a multi-year term, can be significant at scale.
How to fix:
- Run a licence usage report before renewal: M365 Admin Centre → Reports → Microsoft 365 Apps Usage. Identify users on E5 who have not used Defender for Endpoint, eDiscovery, or PIM in the past 90 days.
- Segment your user population: executives, finance, legal, IT, and security teams typically need E5. Knowledge workers doing email, Teams, and document collaboration typically need E3. Frontline workers — factory floor, retail, field staff — need F1 or F3. Mixing tiers correctly for a 1,000-user enterprise can save ₹30–60 lakhs annually.
- Avoid blanket Copilot licence assignments. Microsoft 365 Copilot at ₹2,500+/user/month requires active usage to justify cost. Deploy to a defined pilot group, measure adoption and value, then expand based on evidence — not organisational pressure.
- Start the renewal review 60–90 days before EA or CSP contract expiry. Microsoft pricing negotiations have more leverage before the renewal deadline, not after.
Mistake #9: No Resilience Plan for Microsoft 365 Outages
Risk: Medium — Business Continuity, Operational Resilience
Microsoft 365 has experienced multiple significant outages since 2020 — including a February 2026 incident where the M365 Admin Centre itself went offline, leaving IT administrators unable to manage the tenant during the disruption, and a global Teams and Exchange outage earlier that year. Microsoft’s 99.9% SLA permits up to 8.76 hours of downtime per year — and a single major incident can consume that entire allowance.
Most Indian enterprises have no documented business continuity plan for a Microsoft 365 outage. When Teams goes down, there is no agreed fallback communication channel. When Exchange is unavailable, there is no process for routing urgent external communications. When the Admin Centre is inaccessible, IT teams have no PowerShell or Graph API runbooks to perform emergency user management. The result is exactly what happened to enterprises globally in February 2026 — hours of confusion and paralysis rather than a structured response.
🇮🇳 India Context: Indian enterprises with customer-facing SLAs — particularly in BFSI, e-commerce, and healthcare — face compounding risk during M365 outages. If customer communication depends entirely on Exchange Online and Teams, a 4-hour outage is a potential SLA breach with contractual and regulatory consequences. SEBI-regulated entities and RBI-regulated financial institutions have specific business continuity obligations that must account for third-party cloud service disruptions.
How to fix:
- Document a Microsoft 365 outage runbook: what is the fallback communication channel (WhatsApp group, mobile numbers list, secondary email), who is the incident owner, and what is the first action in each outage scenario (Exchange down, Teams down, Admin Centre down, full tenant unavailable).
- Invest in PowerShell and Microsoft Graph API competency in your IT team. When the M365 Admin Centre is inaccessible, PowerShell via Graph API remains functional for user management, licence assignment, and security operations.
- Set up a third-party M365 service health monitoring tool — Microsoft’s own Service Health Dashboard is unavailable during Admin Centre outages, which is precisely when you need it most. Tools like MSPbots, Pulseway, or a custom Graph API status poller provide independent monitoring.
- Test your outage response annually — a tabletop exercise simulating a 4-hour Exchange Online outage reveals gaps in your fallback process before a real incident does.
Quick Reference: All 9 Mistakes at a Glance
#1 — Conditional Access not enforced: Enable Security Defaults or create CA policies, move Report-Only to On
#2 — Too many Global Admins: Reduce to 2–3 break-glass accounts, use delegated roles, enable PIM
#3 — Legacy authentication still active: Block via Conditional Access, disable SMTP AUTH at tenant level
#4 — No M365 backup: Deploy a third-party backup solution covering Exchange, SharePoint, OneDrive, Teams
#5 — External sharing unrestricted: Set sharing level to ‘Existing guests’, enforce link expiry in SharePoint Admin Centre
#6 — Purview unconfigured: Enable audit logging, create DLP policies for Indian sensitive data types, define retention rules
#7 — Copilot deployed without governance: Fix permissions first, enable per OU, accept DPA, update privacy notice
#8 — Wrong licence tier: Run usage report, segment by role, right-size before July 2026 price increases
#9 — No M365 outage plan: Document fallback runbook, build PowerShell competency, deploy independent monitoring
Where to Start
If you are doing a first pass, prioritise in this order: enforce Conditional Access (#1), audit and reduce Global Admin accounts (#2), and block legacy authentication (#3). These three address the most common initial access vectors in M365 environments and together represent the security baseline that Microsoft’s own guidance designates as non-negotiable.
The backup misconception (#4) is the mistake most likely to result in irreversible data loss. If your organisation does not have a third-party M365 backup solution in place, that is the most urgent infrastructure gap to close — the consequences of discovering this during a ransomware incident or accidental mass deletion are permanent.
The DPDP Act items — Purview configuration (#6), Copilot governance (#7), and external sharing (#5) — are increasing in urgency as enforcement-readiness expectations move from aspiration to requirement in 2026. An M365 environment with no DLP policies, no audit logging, and unconfigured external sharing is one regulatory inquiry away from demonstrating that no reasonable security safeguards were in place.
The licensing and resilience items (#8 and #9) are lower-risk operationally but represent significant recoverable value — cost savings at renewal and operational continuity during a service disruption that, based on Microsoft’s recent track record, is not a question of if but when.
