Conditional Access

Conditional Access is where device compliance and identity posture stop being advisory. Decolla builds the Entra CA policy set in strict order — break-glass accounts first — inside your own tenant, from a written plan you approve before anything runs.

Why this matters

Conditional Access is the enforcement layer of Entra ID. Intune can mark a device non-compliant all day; until a policy requires a compliant device for cloud apps, that status changes nothing. The same goes for MFA registration: if legacy authentication endpoints still accept a bare username and password, attackers simply route around the front door — password spray campaigns favour those endpoints precisely because they cannot enforce MFA.

The reason so many tenants stay half-protected is not ignorance — it is fear. Every experienced admin knows a story of a Conditional Access change that locked an organisation out of its own tenant, including the administrators who could have fixed it. So policy sets accrete cautiously: report-only pilots that never graduate, exclusion groups that quietly swallow whole departments, and a posture that looks finished in the portal but does not actually bite.

What a good build does

Decolla builds the set in strict order, and the order is the point. Break-glass emergency-access accounts come first — created, then excluded from every subsequent policy before a single blocking control exists. That is the lockout protection every cited baseline mandates, and the step most often skipped by hand because it is tedious to do properly.

The policy set then lands as a coherent whole rather than an accretion: requiring compliant devices for cloud apps and blocking legacy authentication, alongside the administrator, session and platform controls that close the quieter gaps. The risk-based policies are deliberately gated: sign-in risk and user risk carry an Entra ID P2 licence tag and are checked against your tenant's actual licensing by the readiness check — Decolla will not deploy a policy your licences cannot power.

Every policy appears in the written, itemised plan before anything runs, each with its delivery method and reversibility class stated. Deployment is unattended, in your own tenant, and each policy Decolla creates can be rolled back individually — rollback covers Decolla's own changes, not a general undo of your tenant.

Where it bites people

Two failure modes dominate this area in practice:

• The self-lockout. An admin enables a require-MFA or require-compliant-device policy while their own devices are not yet compliant, or before an excluded emergency account exists. Existing sessions survive until token refresh, so the mistake looks fine for a while — then every administrator is locked out at once, and the account that could fix it is subject to the same policy. Break-glass accounts built first, excluded from policy one onwards, are the only reliable defence, which is why Decolla will not sequence this section any other way.
• Risk policies without the licence. The sign-in risk and user risk controls are visible in every tenant, so they get configured in tenants holding only P1 licences — where they are unsupported: they fail to evaluate risk as intended, or put the tenant out of licence compliance. Decolla's P2 tag and readiness gate surface this before the plan is approved, not after a policy fails silently.

What's in this section (14 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.