A Conditional Access baseline where the real constraints are shared tablets, service accounts, and an unapproved P2 budget
Fabrikam has 1,200 employees licensed Microsoft 365 E3 and 250 warehouse staff licensed Microsoft 365 F3. Per-user MFA is still set to Enabled for 800 users from a 2019 rollout. A line-of-business inventory application authenticates to Exchange Online with IMAP basic auth using three service accounts. The security team wants a Conditional Access baseline: MFA for all users, block legacy authentication, and an 8-hour sign-in frequency for the 60 finance users. Warehouse staff share Android tablets and will not be issued phones or Authenticator on personal devices. Finance users travel to a partner site for two weeks each quarter and must not be locked out. Entra ID P2 add-on budget is unapproved; only what ships with E3 and F3 is available.
1. Which parts of the requested baseline can you enforce with the licences you have, and which need P2? State the licensing rule for Conditional Access precisely.
Read the worked answer
Everything requested is P1, and P1 is already paid for. MFA, block legacy authentication, sign-in frequency, and named locations are Conditional Access features included in Entra ID P1, which ships with both Microsoft 365 E3 and Microsoft 365 F3. The unapproved P2 budget is not a blocker for this baseline.
What would genuinely need P2 (defer, and say so in the design document): sign-in risk and user risk conditions, PIM, access reviews, and risk-based policies. Expect Identity Secure Score to keep recommending them - that is not a reason to buy.
The licensing rule to state explicitly: Conditional Access licensing is per targeted user. A user without P1 is not evaluated against the policy. They are not blocked - they are silently unprotected, which is the worst outcome, because the portal looks green while 250 warehouse accounts sit outside the control. Before enabling, confirm every member of 'All users' holds E3 or F3, and exclude only the two break-glass accounts with a documented reason.
Rollout: report-only for two weeks, then review the Conditional Access insights workbook for users with no policy applied, then switch to On workload by workload. Turn on 'block legacy authentication' last, because that is the one that breaks things visibly.
2. Design the MFA experience for the 250 warehouse staff who share Android tablets. What are you ruling out and why?
Read the worked answer
Ruling out: excluding warehouse users from MFA (a permanent hole reachable from any device on any network), and issuing 250 FIDO2 keys (lost keys, shift handover problems, and per-key cost against high seasonal turnover).
Recommended: Microsoft Authenticator shared-device mode on the tablets.
- The tablet is configured once in shared device mode; Authenticator signs each worker in and out per shift, so the credential follows the person, not the hardware.
- Each worker still enrols their own second factor once, in a supervised session using a Temporary Access Pass so nobody is prompted for a method they have not registered yet.
- Require MFA for the warehouse group, but do not add device-compliance or app-protection conditions unless the tablets are actually enrolled in Intune. Check the F3 entitlement for device management before promising it.
If shared-device mode is rejected: certificate-based authentication on the tablets (P1) is the next best option - device-bound and phone-free. Only as a last resort use a named-location exclusion for the warehouse network, and then also block those accounts from authenticating from any other location so the exclusion cannot be replayed from outside.
Compensating control: put these 250 accounts in scope for sign-in anomaly monitoring. Shared-device credentials are the classic lateral-movement path, and MFA alone does not change that.
3. How do you retire the per-user MFA state and handle the IMAP service accounts without breaking the application or leaving a permanent hole?
Read the worked answer
Per-user MFA first. Run the new CA policy in report-only for two weeks, fix the gaps, switch it On, then set the legacy per-user state from Enabled to Disabled in batches. Leaving both is not defence in depth: per-user MFA is evaluated independently of Conditional Access, cannot be scoped by group or condition, prompts users twice, and hides from your sign-in logs which control actually satisfied the requirement. Keep Enforced only for accounts you cannot move yet and track them as technical debt with a date.
IMAP service accounts. Blocking legacy authentication will break them - that is the purpose of the control, so fix the application rather than the policy:
- Ask the vendor for OAuth 2.0. If it exists, migrate to an app registration with Exchange Online application permissions and scope it with an application access policy so it can only touch those three mailboxes.
- Interim if it does not: an explicit, documented exclusion of those three accounts from the legacy-auth block, plus block interactive sign-in for them via CA, restrict their authentication to the app server's egress IP with a named location, and alert on any sign-in from elsewhere.
- Put an expiry date on the exclusion. Microsoft has scheduled retirement of basic authentication for client submission protocols in Exchange Online, so the app will break regardless - better on your timetable than the service's.
These accounts should also be excluded from the MFA policy. Service accounts cannot complete interactive MFA, and a shared MFA method registered to a team is worse than a scoped, monitored exclusion.