Skip to main content
Entra Conditional Access, India

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.

Book a Conditional Access reviewSee the policy framework
Microsoft
Microsoft
Entra ID
Cloud Solution Partner
  • Every sign-inEvaluated by policy
  • P1 or Business PremiumYou may already own it
  • Report-only firstNothing enforced blind
  • Break-glassTested, not assumed
The policy framework we deploy

Eight policy categories, one coherent set.

A Conditional Access policy is an if-then statement: if this user, from this location, on this device, at this risk level, then require this. What makes a policy set hold is not any individual rule but how the rules interact and what sits outside them. This is the standard framework we design for Indian organizations, adapted to your licensing and device posture.

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.

How Conditional Access deployments actually fail

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.
Ask us to check your tenant for these
How we design it

Four disciplines that keep the policy set working after we hand it over.

Conditional Access is easy to make complicated and hard to make simple. A set nobody can explain is a set nobody maintains, and it drifts toward exceptions within a year.

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.

Who needs this

Six Indian situations where Conditional Access is the deciding control.

The common thread: identity is now the perimeter. The policy set is what actually stands between an attacker holding a stolen password and your data, and increasingly it is what regulators, insurers and enterprise clients ask about first.

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.

Three tenant positions

What we find when we open Conditional Access in Indian tenants.

The middle column is the most common and the most misleading, because the organization believes it has a control. It has a policy list, and the exclusions and drift have quietly made much of it optional.
Feature
Designed and maintained
Policies with drift
Security defaults or nothing
MFA enforced for all users
MostlyPartly
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 exceptionsNot applicable
Every exclusion has a name and reason
Not applicable
Break-glass tested and monitored
Exists, untestedNone exist
Policies staged in report-only first
SomeNot applicable
Sign-in logs reviewed after go-live
Frequency in the Indian market
UncommonCommonCommon in SMEs
Licensing, without the sales pitch

What each capability actually requires.

Based on Microsoft published licensing statements. The commercially important row is the second one: many Indian SMEs on Microsoft 365 Business Premium already own Conditional Access and have never opened it. The other important row is risk-based policies, which need P2, because a lot of published guidance quietly assumes a licence you may not hold.
CapabilityWhat it needs
Security defaults (preset baseline)Available to every tenant, no premium licence
Conditional Access policiesEntra ID P1, also included with Microsoft 365 Business Premium
Require MFA, block legacy authenticationP1
Location and named-network conditionsP1
Require compliant or hybrid-joined deviceP1, plus Intune for device compliance
App protection policies on mobileP1, plus appropriate Intune licensing
Phishing-resistant MFA (FIDO2, Windows Hello)P1, authentication strengths
Report-only mode and What If testingP1
Sign-in risk and user risk policiesP2, via Microsoft Entra ID Protection
If licences lapsePolicies keep running and can be viewed or deleted, but not edited
How an engagement runs

Five stages, and nothing is enforced until stage four.

Typically two to four weeks end to end, delivered remotely from Gachibowli, Hyderabad for organizations anywhere in India. Most of the elapsed time is report-only observation, which cannot be compressed without accepting lockout risk.
  1. 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. 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. 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. 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. 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.

Straight answers

What Indian organizations ask about Conditional Access.

Not if the rollout is staged properly, and this fear is the reason many tenants have no policies at all. Three safeguards make lockout practically impossible: break-glass emergency accounts excluded from every policy, tested and monitored, so administrators always have a way in; report-only mode, where every policy shows what it would have blocked for days or weeks before it blocks anything; and enforcement in waves, starting with IT, so any surprise hits the people best equipped to handle it. The lockout stories you hear come from tenants that skipped all three.

They get inventoried before anything is enforced, which is the step that separates a smooth rollout from a broken Monday. Sign-in logs show every non-human account, where it signs in from and what protocol it uses. What can move to managed identities or certificate-based app registrations moves, because those are not subject to password attacks at all. What cannot move gets a deliberate exemption scoped to the narrowest possible conditions (specific app, specific source location), with a named owner and a review date. Undocumented blanket exclusions are how policy sets rot.

Nothing, if the policy set was designed rather than accumulated. Travel is a condition to design for, not an exception to grant at midnight. The pattern that works: device compliance and MFA as the constant requirements that apply everywhere, stronger step-up from unfamiliar locations, and no blanket country blocks for ordinary users. A director in Singapore on a compliant laptop with MFA signs in normally. A stolen password replayed from anywhere does not. Blanket geo-blocking mostly punishes your own travellers while attackers route around it.

This is a real attack pattern: bombard a user with push notifications until they approve one to make it stop. The fixes are number matching, where the user must type a code shown on the sign-in screen rather than tapping approve, which Microsoft now enforces for Authenticator push; limiting how often prompts appear, because MFA at every sign-in trains people to approve reflexively; and for administrators, phishing-resistant methods such as FIDO2 keys or Windows Hello, which cannot be approved by a tired thumb because there is nothing to approve. We configure all three as part of the design.

Yes, and you should, but in the right order. First identify what actually uses legacy protocols from the sign-in logs; the usual finds in Indian tenants are scan-to-email devices, Tally and ERP mail connectors, old scripts and one veteran employee on an ancient mail client. Then migrate what can migrate: modern auth for mail clients, SMTP with OAuth or a relay for devices. Then block legacy authentication for everyone else, which closes the single most abused sign-in path in Microsoft 365. Blocking it blind on day one is what breaks invoicing; never blocking it leaves MFA bypassable.

Yes, and it is one of the strengths of the model. Policies scope to specific applications, so the sensitive ones (finance systems, HR data, admin portals) can require a compliant device while the low-risk ones stay lighter. The discipline is restraint: per-app policies multiply quickly, and a tangle of thirty app-specific rules is unmaintainable. We design a strong baseline that covers everything, then add per-app tightening only where the data sensitivity genuinely justifies it, which is usually a handful of applications.

The identity section of most questionnaires reduces to four questions: MFA enforced for all users, MFA (usually phishing-resistant) for administrators, legacy authentication blocked, and documented emergency access procedures. A designed policy set answers all four truthfully in your favour, and the policy configuration plus sign-in logs are the evidence if the insurer or a claims assessor asks. The dangerous position is answering yes while three service accounts and two executives sit outside every policy, because an inaccurate questionnaire answer is exactly what claim disputes are built on.

Conditional Access itself requires Entra ID P1, and Microsoft 365 Business Premium includes it, which is the fact most Indian SMEs miss: if you hold Business Premium, you already own Conditional Access. P2 adds Identity Protection, which is what enables risk-based policies (block or challenge sign-ins that look like credential replay) plus Privileged Identity Management for just-in-time admin roles. Most SMEs get a strong policy set on P1 or Business Premium alone. Regulated firms and larger organizations usually justify P2 for the risk signals and PIM. Our comparison page on P1 vs P2 covers the decision in depth.

No. Security defaults are a preset baseline Microsoft makes available to every tenant: MFA registration for all users, legacy auth blocked, extra protection for admins. They are much better than nothing and they are blunt: the same settings for everyone, no exclusions, no device conditions, no location logic, no per-app scoping. The moment you need to treat administrators differently, require compliant devices, or handle a service account deliberately, you have outgrown defaults and need Conditional Access policies. The two are alternatives; enabling policies means designing what replaces the defaults.

Fewer than you expect. A typical well-designed SME tenant lands somewhere around eight to twelve policies: the MFA baseline, the legacy auth block, device requirements, admin protection, travel and location handling, risk policies if P2 exists, and a small number of app-specific rules. A set your administrator can explain in ten minutes is a set that stays maintained. Tenants with forty accumulated policies are not more secure; they are unexplainable, and unexplainable sets drift toward exceptions until they are decorative.

Sign-in logs are the feedback loop. In the first weeks we look for two things: unexpected blocks, which are usually a missed service account or an unanticipated user pattern, and unexpected passes, which are gaps in coverage. Beyond that, exclusions get re-justified on a schedule and removed when nobody can defend them, new applications get brought under policy as they arrive, and Microsoft changes (new policy capabilities, deprecations, preview features becoming default) get evaluated as they land. Tuning is light work, but skipping it entirely is how a good policy set decays back to a tangle within a year or two.

Yes, and almost every Conditional Access engagement we deliver is fully remote. The work is tenant configuration, log analysis and structured conversations with your team, none of which needs anyone on site. We are based in Gachibowli, Hyderabad and serve organizations across India over screen-share sessions scheduled around your team, with all changes made in your tenant under accounts you control and can audit. Initial enquiries get a reply within 4 business hours.
Check your own tenant today

Fifteen questions you can answer from the portal this week.

The first group establishes what exists. The second finds the gaps that cause incidents. The third asks whether the set would survive a real attacker, a cyber-insurance questionnaire, or an auditor.

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.
Related reading

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 more

Entra ID P1 vs P2

The licence decision in depth: what P1 covers, what genuinely needs P2, and how to decide without overbuying.

Learn more

Microsoft 365 Security Audit

A full tenant review where Conditional Access gaps are one finding among many, alongside mail, sharing, and audit retention.

Learn more
References

Official documentation

Next step

Find 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.

Book a Conditional Access reviewSee Microsoft Entra ID

Related Services

Explore more solutions that work great with this service

Microsoft Entra

Identity and access management solutions

Learn more

Entra ID P1 vs P2

Which identity plan your business needs

Learn more

Entra ID Governance

Access reviews, PIM and lifecycle automation

Learn more

Microsoft 365 Security Audit

Read-only tenant security assessment

Learn more