Skip to main content

Glossary

Conditional access

Conditional access is the practice of granting or refusing access to company resources based on conditions evaluated at sign-in: who the user is, whether the device is compliant, where the request comes from, and how risky it looks. Instead of one password granting everything, each attempt is judged on its own.

How it works

Think of a rule as a sentence: if this user, on this device, from this place, asks for this application, then allow, block, or allow with extra proof. The signals come from several sources. Identity contributes the account and its group memberships, usually from Microsoft Entra ID. The device contributes its compliance state, reported by the MDM: encryption on, OS up to date, no jailbreak, a passcode set. The network contributes the IP address and country.

The outcome is rarely a flat no. Most rules ask for something extra instead: multi-factor authentication, a managed browser, or a session that expires faster. Microsoft introduced Conditional Access with Azure AD Premium and keeps extending it, and since 2024 it has been pushing mandatory MFA for admin sign-ins to its own portals, which tells you where the defaults are heading.

Why it matters for a fleet

A stolen password used to be enough to read someone's mailbox from a laptop in another country. Conditional access breaks that, because the request now also has to come from a device the company knows and trusts. That is the single biggest return on an MDM deployment that most teams underestimate.

It does need care. Rules that look reasonable on paper lock out the CFO at an airport, and a badly scoped policy can lock out the administrators who would fix it. Always keep a break-glass account excluded from your rules, run new policies in report-only mode first, and write down what each rule is for. Six months later, nobody remembers.

One honest limitation: device compliance is only as good as the freshness of the data behind it. A device that last checked in four days ago is reported compliant but is really unknown, so treat check-in age as a condition too.

How Appaloosa handles it

Appaloosa evaluates compliance continuously on enrolled iOS, Android and Windows devices: OS version, passcode, BitLocker encryption on PCs, required apps, last check-in. A device that falls out of the rules can be notified, lose access to managed apps, or have its work data wiped. That compliance state reported by the MDM can also feed the access decisions made by your identity provider, which is where conditional access gets its device signal. The Windows policies are listed on the Windows MDM page.

Explore

See the full platform

Enrollment, apps, security, remote support: all in one place.

Explore Appaloosa

See Appaloosa run on your fleet Book a demo

Frequently asked questions

Is conditional access the same as multi-factor authentication?
No. MFA is one possible outcome of a rule, not the rule itself. Conditional access decides when MFA is required, when access is blocked outright, and when a known compliant device on the office network can sign in without an extra prompt.
Do I need an MDM for conditional access?
You can write rules on identity and network signals alone, but device compliance is the signal that actually proves the endpoint is safe. Without an MDM reporting encryption, OS version and passcode state, you are trusting the user's word about the machine.
How do you avoid locking everybody out?
Start in report-only mode to see who a rule would have blocked, exclude at least one emergency account with a long stored password, and roll out group by group. Also test the path a traveling user takes, because country conditions cause most surprise lockouts.