Conditional Access: who needs a licence

One Business Premium licence may let an administrator create a Conditional Access policy, but it does not license every user covered by it. Learn how to determine who needs Entra ID P1 or P2 and roll out policies safely.

Conditional Access decides access according to login conditions. For example, a business may require additional authentication or certain device features. Common user scenarios require a Microsoft Entra ID P1; risk-based rules need corresponding P2 permissions. The fundamental signpost is current Microsoft Entra licensing.

Start the purpose of the rule

Conditional access is not a one-size-fits-all security option. Before the proposal, write the sentence: "This group of people can access this service only under these conditions." If you cannot complete the sentence, it will be difficult to judge the license and the impact of the change.

Differentiate between normal employee, administrator, external guest and application logins. These are not interchangeable identities. This article focuses on internal users; external identities and workload identities have their own license and technical terms.

Also, separate the signal you want to use from the product that provides it. Requiring compliant equipment is not just an Entra issue. You need to know how device status is determined and whether this part of the solution is licensed.

How to calculate the range

Take the users and groups included in the rule. Check exceptions, additional rules and actual logins. The number of licenses purchased should not be based solely on the number of people in the security team.

Hypothetical example: the company has 60 internal employees, ten of them Business Premium and the rest Business Standard. The rule requiring MFA should apply to all 60 via Conditional Access. You need to evaluate the permissions of the entire target group, not just ten users with Premium.

It is not necessary for everyone to automatically buy the same set. For each role, find out whether the required authorization is already included in its product, whether a separate license can be suitably added, and which other services it really uses. Record the result by users or maintained groups.

What to compare when designing

The table is a control aid, not a complete product price list. Confirm exact SKU, available services and target population when purchasing.

Security defaults can be a good place to start

Microsoft also offers security defaults. For a simple environment, they can be a reasonable basis. But using them doesn't mean you have the same flexibility as you would with your own Conditional Access rules.

Plan the transition as a change to login protection. Record what the current state provides and which new mechanism will take over. Don't remove existing protection just to try a new interface in peace.

For a small business, compare your needs: is a uniform default protection sufficient, or does it have different requirements for branches, sensitive applications or device management? A more complex configuration makes sense when it solves a documented problem and someone will manage it long-term.

The rules are made up, there is no single winner

A user can fall under multiple rules. Microsoft describes their concurrence in the Conditional Access policies documentation. Therefore, check all applicable policies when diagnosing.

A rule requiring MFA may not resolve a situation where another rule blocks access or additionally requires a compliant device. The administrator then often switches licenses unnecessarily, even though the problem arises from a combination of conditions.

For each job role, write down the expected login paths: laptop, phone, web, company apps. Use this list as test scenarios. Success on one administrative laptop does not yet confirm that the work of the entire company will work tomorrow.

Safe installation procedure

1. Export existing policies and describe their purpose.
2. Check the licenses of the target users and the necessary related services.
3. Select a pilot group covering common work scenarios.
4. Use report-only mode where appropriate for the test and evaluate the login.
5. Verify user readiness and support of clients in use.
6. Turn on the rule for the pilot and see the real impacts.
7. Distribute in groups with a return procedure in place.

In report-only, the rule is evaluated without the normal enforcement of its requirements. The regime serves to assess the impact; do not treat it as an already deployed protection. Details and limitations are described by Microsoft in the report-only documentation.

How to solve a blocked login

Ask for time, account, app and device. Check the login logs to see which policy made the decision. Don't start by adding people to exceptions across the board.

In practice, a single incident tends to be a mix of things: missing authentication registration, old client, incorrect device state, or a policy targeting a different group than the administrator intended. Resolve the confirmed cause and retry the original work task.

Each required exception should have a reason, owner and review date. Without this data, a temporary fix gradually turns into a permanent protection gap.

What to watch for in a multi-license environment

Mixed licenses require an overview of groups and products. If a person changes roles, it's not just the license that needs to change. It can enter a different target group and begin to be subject to a policy for which the new product is not enough.

Therefore, combine role approval, product assignment and security scope. Verify the change from both sides: the user is authorized and the policy is actually applied. One green item in the license overview does not cover the entire process.

Practical control output

Create a simple binding: policy → work role → target users → required permissions → login test. Update the overview regularly when joining, leaving and changing roles. This will prevent a situation where a properly functioning policy no longer matches the licenses.