Conditional Access is the policy engine deciding every sign-in. Most tenants have never designed it.
Every time someone signs in to Microsoft 365, Conditional Access decides who, from where, on what device, with what risk, gets what. Most Indian tenants sit at one of two extremes: no policies at all, or a tangle of rules that blocks the CEO the moment they land abroad. We design a coherent policy set, stage it in report-only mode so nothing locks out the business, and tune it after go-live.
- Every sign-inEvaluated by policy
- P1 or Business PremiumYou may already own it
- Report-only firstNothing enforced blind
- Break-glassTested, not assumed
Eight policy categories, one coherent set.
Baseline: MFA for all users
The anchor policy. Every user, every application, multifactor authentication required, targeted at all users rather than a group somebody has to remember to maintain. Exclusions are limited to the break-glass accounts and documented service accounts, each with a named owner and a reason. This one policy defeats the plain password-guessing and phishing attacks that account for most tenant compromises we investigate.
Baseline: block legacy authentication
Legacy protocols such as IMAP, POP and SMTP basic auth cannot perform MFA, which makes them the path attackers try first. An MFA policy without a legacy-auth block is a locked front door with an open window. We identify what still uses legacy auth in your tenant (old scanners, scripts, ERP connectors are the usual suspects), migrate or exempt them deliberately, then block the rest.
Device-based access
Require a compliant device (managed by Intune and meeting your compliance policy) or a hybrid-joined device for access to corporate data. This is the control that turns device management from a report into an access decision: an unmanaged personal laptop can no longer open SharePoint just because the password was right. Where full device enrolment is too heavy, app protection policies cover mobile access instead.
Location and travel handling
Named locations for your offices and expected geographies, with travel treated as a designed condition rather than an emergency exception. The classic failure is a country block added after an incident that then strands a director at a conference abroad. We design location policies that tighten risk without breaking travel: stronger requirements from unfamiliar locations rather than blanket blocks.
Admin protection: phishing-resistant MFA
Privileged roles get a stronger policy than everyone else: phishing-resistant MFA (FIDO2 security keys or Windows Hello for Business) rather than approvable push notifications, because an admin who can be phished is a tenant that can be taken. Global Administrator, Exchange Administrator, SharePoint Administrator and the other high-impact roles are scoped explicitly, and admin sessions get shorter sign-in frequency.
Risk-based policies, where P2 exists
With Entra ID P2, Identity Protection feeds real-time sign-in risk and user risk into policy: a sign-in that looks like credential replay can be blocked or forced to re-authenticate even though the password was correct. Microsoft states these risk-based policies require P2, so we design them only where the licence exists, and we never hand a P1 tenant a design it cannot deploy.
Break-glass emergency accounts, done right
Two emergency access accounts excluded from every Conditional Access policy, so a misconfigured policy can never lock every administrator out of the tenant. The exclusion is deliberate and it creates a permanently excluded privileged account, so it is handled properly: long random credentials stored offline, an alert that fires the moment either account signs in, and a periodic test that confirms they actually work.
Report-only staging and monitoring
Every policy runs in report-only mode before enforcement, showing exactly what it would have blocked without blocking anything. We read those results with you, resolve the surprises (there are always surprises), then enforce in waves with administrators first. After go-live, sign-in logs are monitored so the policy set is tuned on evidence rather than complaints.
Three failure stories we see repeatedly in Indian tenants.
None of these are exotic. Each one comes from skipping a step that takes hours, and each one costs days of disruption plus the goodwill of the people most likely to veto security work in future.
- The locked-out executive. A location policy blocks sign-ins from outside India. The managing director lands in Singapore for a client meeting and cannot open email. IT gets the call at midnight, panics, and disables the entire policy rather than fixing the design. The tenant is now less protected than before the project started, and the next security proposal gets a colder reception. Travel has to be designed as a condition, not handled as an exception.
- The blocked service account. An MFA-for-all policy goes live on a Friday. On Monday the attendance system has not synced, invoices have not gone out, and a warehouse scanner has stopped working, because three service accounts that authenticate with passwords were never inventoried. The fix is not excluding them in a panic; it is finding them before enforcement, moving what can move to managed identities, and documenting deliberate exemptions for the rest.
- The forgotten break-glass account. A policy change goes wrong and locks out every administrator. The emergency account exists, but nobody has tested it in two years, its password is in a former employee notebook, and its MFA registration points to a phone that was returned to the operator. Recovery means a support case with Microsoft and days of downtime. A break-glass account that is not tested and monitored is not emergency access, it is an assumption.
- The common thread: every one of these is prevented by report-only staging, a service-account inventory, and a tested emergency path. That is why our process refuses to enforce anything until those three exist.
Four disciplines that keep the policy set working after we hand it over.
Licence check before anything else
Microsoft includes Conditional Access with Entra ID P1 and with Microsoft 365 Business Premium, and risk-based policies need P2. We establish exactly what you hold before designing anything, because a design built on features you are not licensed for cannot be deployed, and recommending an upgrade you do not need is the fastest way to lose your trust. Often the gap is configuration, not licensing.
Service accounts inventoried before enforcement
Enforcement day incidents come from the accounts nobody thought about: the attendance sync, the Tally connector, the scan-to-email device, the backup job. We inventory every non-human sign-in from the logs before any policy is enforced, migrate what can move to managed identities or app registrations, and document a deliberate, reviewed exemption for whatever remains.
Report-only first, every time, and we read the results
Every policy runs in report-only mode before enforcement, and we work through what it would have blocked with the people affected, using What If to model specific users and scenarios. Conditional Access failures are highly visible and land on senior people. An unannounced enforcement that blocks the finance team during month-end closing costs more goodwill than the policy was worth.
Simple enough for your team to own
A small set of policies targeting all users with documented exclusions beats a large set targeting groups somebody must remember to maintain. We hand over a one-page written explanation of what each policy does and why each exclusion exists, and we set a review date for re-justifying the exclusions. The test: your administrator can explain the whole set in ten minutes.
Six Indian situations where Conditional Access is the deciding control.
SMEs on Business Premium who never configured it
The most common situation we find and the easiest to fix. The licence was bought for the security features, Conditional Access was never opened, and the organization is protected by whatever defaults happen to apply. There is nothing to buy and no procurement conversation to have. The entire gap is configuration, which makes it unusually easy to justify internally.
Organizations under DPDP Act obligations
The Digital Personal Data Protection Act requires data fiduciaries to implement reasonable security safeguards for the personal data they process. For a Microsoft 365 estate, controlling who can reach that data, from what device and under what conditions, is exactly what Conditional Access does, and it produces sign-in evidence you can show when someone asks how access is controlled.
Companies filling in cyber-insurance questionnaires
Insurers now ask directly: is MFA enforced for all users, is it enforced for administrators, is legacy authentication blocked, do you have emergency access procedures. These questions are answered accurately or not at all, and a mis-answered questionnaire is a claim dispute waiting to happen. A designed policy set answers most of the identity section truthfully in your favour.
IT services firms and GCCs with travelling staff
Consultants at client sites, delivery leads travelling abroad, developers working from anywhere. This is where naive location blocks cause the most damage and where designed travel handling earns its keep: stronger authentication requirements from unfamiliar locations, device compliance as the constant, and no midnight calls from stranded executives.
Regulated financial and listed entities
RBI cyber-security guidance, SEBI frameworks for regulated intermediaries, and CERT-In directions all expect demonstrable access control and MFA on critical systems. Conditional Access is where most of that answer lives for a Microsoft estate, with policy configuration and sign-in logs as the evidence an assessor actually accepts.
Remote-first and hybrid workforces
When nobody sits behind an office firewall, the sign-in decision is the only perimeter you have. Device compliance, app protection on personal phones, and MFA everywhere become the controls that matter. We design for the workforce you actually have, including the BYOD reality most Indian companies operate with, rather than an office-bound model.
What we find when we open Conditional Access in Indian tenants.
| Feature | Designed and maintained | Policies with drift | Security defaults or nothing |
|---|---|---|---|
MFA enforced for all users | Mostly | Partly | |
Legacy authentication blocked | Sometimes | ||
Admins under phishing-resistant MFA | Same policy as users | ||
Device compliance gates access | Reported only | ||
Travel designed as a condition | Handled by exceptions | Not applicable | |
Every exclusion has a name and reason | Not applicable | ||
Break-glass tested and monitored | Exists, untested | None exist | |
Policies staged in report-only first | Some | Not applicable | |
Sign-in logs reviewed after go-live | |||
Frequency in the Indian market | Uncommon | Common | Common in SMEs |
What each capability actually requires.
| Capability | What it needs | |
|---|---|---|
| Security defaults (preset baseline) | Available to every tenant, no premium licence | |
| Conditional Access policies | Entra ID P1, also included with Microsoft 365 Business Premium | |
| Require MFA, block legacy authentication | P1 | |
| Location and named-network conditions | P1 | |
| Require compliant or hybrid-joined device | P1, plus Intune for device compliance | |
| App protection policies on mobile | P1, plus appropriate Intune licensing | |
| Phishing-resistant MFA (FIDO2, Windows Hello) | P1, authentication strengths | |
| Report-only mode and What If testing | P1 | |
| Sign-in risk and user risk policies | P2, via Microsoft Entra ID Protection | |
| If licences lapse | Policies keep running and can be viewed or deleted, but not edited |
Five stages, and nothing is enforced until stage four.
- 1
Establish what you have
2-3 days
Licence position (P1, P2, Business Premium), existing policies and their exclusions, whether security defaults are on, device management posture, and what still signs in with legacy authentication. Output: a current-state summary and the list of things that would break under naive enforcement.
- 2
Inventory the non-human sign-ins
2-3 days
Every service account, script, connector and device identified from sign-in logs, with an owner traced for each. What can move to managed identities or certificate-based app registrations moves. What cannot gets a documented, scoped exemption with a review date. This stage is what prevents the Monday-morning breakage stories.
- 3
Design the policy set
2-4 days
The framework adapted to your licence and device posture: MFA for all, legacy auth blocked, device or app protection requirements, location and travel handling, phishing-resistant MFA for privileged roles, risk policies where P2 exists. Deliberately few policies, each with a written purpose. Break-glass accounts created, secured and alert-wired before anything else changes.
- 4
Stage in report-only, then enforce in waves
1-2 weeks
Every policy runs report-only while we read what it would have blocked and resolve the surprises with the people affected, using What If to model specific scenarios. Enforcement then rolls out in waves: IT first, then pilot groups, then everyone, with help-desk briefed before each wave and break-glass tested before the first one.
- 5
Monitor, tune, hand over
Ongoing
Sign-in logs reviewed after go-live for unexpected blocks and unexpected passes, policies tuned on that evidence, and a written handover your team can maintain: what each policy does, why each exclusion exists, and a scheduled review point where exclusions are re-justified or removed. Managed clients get this ongoing under our managed support, with a 30 minutes response SLA.
What Indian organizations ask about Conditional Access.
Fifteen questions you can answer from the portal this week.
What exists today
- Are you on security defaults, Conditional Access policies, or neither?They are alternatives. Many tenants have neither fully in force.
- Do you hold Entra ID P1, P2, or Business Premium?P1 and Business Premium both include Conditional Access. Check before buying anything.
- How many policies are enforced versus report-only?A tenant full of report-only policies is enforcing nothing.
- Is MFA required for all users, or only for some group?Group-targeted MFA drifts as membership drifts.
- Is legacy authentication blocked?It cannot do MFA and it is the most abused sign-in path.
The gaps that cause incidents
- List every exclusion in every policy. Can each one be justified?The single most valuable exercise on this page.
- Which service accounts authenticate with plain passwords, and from where?These are what break on enforcement day if nobody inventoried them.
- Do break-glass accounts exist, and has anyone tested them this year?Untested emergency access is an assumption, not a control.
- Would an alert fire if a break-glass account signed in?A permanently excluded privileged account must be monitored.
- Are there travel exceptions that were never removed?Temporary exclusions created under pressure rarely get cleaned up.
Would it hold
- Do admin roles have a stronger policy than ordinary users?Phishing-resistant MFA for privileged roles is the control that matters most.
- Does device compliance gate access, or is it only reported?Visible non-compliance that blocks nothing changes nothing.
- Was every enforced policy staged in report-only first?And did someone actually read the report-only results.
- Who reviews sign-in logs after policy changes?Tuning on evidence beats tuning on complaints.
- Could you explain the whole policy set to an insurer or auditor in ten minutes?If not, it is too complicated to stay maintained.
The pages around this one.
Microsoft Entra ID
The wider identity platform Conditional Access lives inside: SSO, MFA, PIM, governance, and the identity practice for a Microsoft estate.
Learn moreEntra ID P1 vs P2
The licence decision in depth: what P1 covers, what genuinely needs P2, and how to decide without overbuying.
Learn moreMicrosoft 365 Security Audit
A full tenant review where Conditional Access gaps are one finding among many, alongside mail, sharing, and audit retention.
Learn moreFind out what your sign-ins are actually allowed to do.
If you hold Entra ID P1 or Business Premium, Conditional Access is already in your tenant waiting to be designed. Tell us where you are (no policies, a tangle, or something in between) and we will tell you what a coherent set looks like for your licence and your workforce. Remote-first from Hyderabad, serving all of India.
Related Services
Explore more solutions that work great with this service