Overe applies policies to your Microsoft 365 tenant on your instruction. Some of those policies — Conditional Access in particular — carry licence requirements under your agreement with Microsoft, and those requirements attach to every user, group, or device the policy targets.

This article explains where that responsibility sits and what to check.

Overe does not verify Microsoft licence entitlement before applying a policy, and does not prevent a policy from being applied to an object that isn't licensed for it. Neither does Microsoft — Entra will accept a Conditional Access policy targeting an unlicensed user, and the policy will take effect on them.

That means a policy can apply successfully, do exactly what you intended, and still leave the tenant outside Microsoft's licensing terms. Nothing in the product or the portal will stop it, though Microsoft has begun surfacing this in the Entra UI.

You determine the scope of any policy applied through Overe. That includes:

The last one is worth calling out. Automated Response acts without an administrator present, so there is no review step at the moment of action. Overe carries out the automation you set up; the decision about who that automation can act on is yours, made when you configure it.

In mixed-licensing tenants. If your tenant combines SKUs — Business Standard alongside Business Premium, for example — confirm that policy scope matches entitlement rather than defaulting to all users. Users without a Conditional Access-eligible licence should be excluded.

Before enabling automated blocks. Account blocks are enforced through a Conditional Access policy, so any user an automation can block needs an eligible licence. If some of your users don't have one, restrict the automation's scope, or use session revocation and alert-only responses, which have no licence requirement.

On an ongoing basis. Licence assignments change. A user who was in scope legitimately when a policy was deployed may not be after a SKU downgrade or a role change.