In the cloud there is no network perimeter — identity is the perimeter. That is why the main control in Entra ID is Conditional Access: a policy that evaluates who signs in, from where and on which device before granting access.
Anatomy of a Conditional Access rule
- Assignments — who it applies to: users, groups, admin roles.
- Conditions — from where: location, device platform, sign-in risk level.
- Access controls — what is required: MFA, a compliant device, or a full block.
- Report-only — a test mode that shows the impact without blocking real users.
Additional layers
- MFA — multi-factor authentication; Authenticator or FIDO2 beats SMS.
- PIM (Privileged Identity Management) — just-in-time admin rights on request and approval instead of standing Global Admin.
- Identity Protection — detects risky sign-ins: impossible travel, password spray, leaked credentials.
- Security defaults — a baseline protection set for small organizations without advanced licensing.
Signals on the left: user and group, device state, location and IP, sign-in risk, target application. They all feed the Conditional Access policy engine. On the right the possible outcomes: grant with MFA, require a compliant device, or block access outright. The rule is never trust, always verify. The bottom bar covers privileges after sign-in: RBAC by role, PIM for just-in-time admin rights, and managed identities instead of secrets in code.