Conditional Access by application: planning when MFA is requested
When reviewing multifactor authentication (MFA), start with a practical question: which application, for which people, under what sign-in circumstances? Record the proposed answer before changing a policy. This is a planning exercise, not a configuration guide.
Microsoft describes MFA as an additional form of identification requested during sign-in. It says Conditional Access policies can define events or applications that require MFA. Those options help frame a review, but they do not determine the right policy for your organisation. Microsoft Entra MFA overview
Start with the application and its users
Choose one application to review. Ask its owner who needs access, then ask the identity team to consider the proposed MFA requirement. You do not need to decide at this point whether the application needs a separate policy.
Make a short record of five things:
- Application: What is under review, and who owns its access decisions?
- Users: Which people or groups need it? Who can confirm the list?
- Reason: Why is an additional sign-in check being proposed?
- Circumstances: When might it be requested? Which situations remain undecided?
- Open questions: Who will check each unknown before any change is considered?
If an application is absent from this record, write “not assessed in this review.” Do not assume it has no MFA requirement. Its owner may know of an earlier assessment or a different access process.
Keep the owner’s access requirements separate from the identity team’s sign-in proposal. For example, an owner may confirm that a particular group uses an application without knowing how its sign-in requirements should be configured. Label what each person has actually confirmed.
Ask when a prompt is proposed
Naming an application does not, by itself, explain when its users should receive an MFA prompt. Microsoft illustrates policies that allow regular sign-in on a corporate network or registered device but request additional verification for remote sign-ins or personal devices. These are examples of possible behaviour, not recommended exceptions for your organisation. Microsoft Entra MFA overview
For the application under review, discuss a few situations in plain language:
| Ask | Record |
|---|---|
| Who is signing in? | The group included in the proposal. |
| Which application? | The application confirmed by its owner. |
| In what circumstances? | Contexts the identity team needs to assess, such as remote access or a personal device. |
| What is proposed? | The additional check being considered, not a claim about current behaviour. |
| What is unknown? | Unconfirmed definitions, methods and user experience. |
This table is a conversation aid, not a policy specification. If someone proposes fewer prompts on a corporate network, ask what the organisation means by that network, which sign-ins the proposal would cover and who will assess it. Leave the suggestion open until it has been reviewed.
Try a hypothetical example
The following is hypothetical. It is not a Q360 customer configuration or a tested policy.
Application: Internal reporting application. Users under review: Staff who use its reports. Proposal: Consider an MFA requirement for those users when signing in to this application. Questions: Would the proposal differ for remote sign-ins or personal devices? Who confirms the user list, permitted verification methods and expected experience? Owners: The application owner confirms access needs; the identity team reviews the sign-in proposal.
The example does not say that MFA is deployed or that a prompt will appear. If the application owner identifies another user group, update the proposed scope. If “personal device” has not been defined for this review, ask the identity team to clarify it rather than treating it as a settled condition.
You can also ask what the team proposes for a staff member using a registered device. Microsoft uses registered and personal devices, along with corporate-network and remote sign-ins, to illustrate how policy behaviour might differ. Your organisation still needs to assess what those contexts mean in its own environment. Microsoft Entra MFA overview
Explain the possible user experience
Microsoft says MFA challenges are handled during Microsoft Entra sign-in. When prompted, users can choose from their registered forms of additional verification. Microsoft Entra MFA overview
That general description does not tell you which methods your organisation permits or which methods its users have registered. Ask the identity team to confirm both before describing the experience to staff. Ask the application owner who will need an explanation and who should receive access questions.
Be specific about the proposal. “MFA for this application” might mean an additional check is being considered for all sign-ins in scope, or that sign-in circumstances are also being assessed. Say which question the team is examining. Do not promise that someone will always, or never, see a prompt based only on a planning note.
Finish with a decision note
Before considering any policy change, label each item in the record confirmed, proposed or unknown. Use those labels to distinguish an owner’s confirmed access requirements from a suggested MFA condition and from questions still awaiting an answer. Do not describe a proposal as an existing control.
Then ask the identity team to review current guidance, licensing, exclusions, configuration and rollout considerations for the organisation’s environment. This guide does not establish that any setting is deployed or that a particular exception is appropriate.
The starting question remains simple: For this application and these users, when is an extra sign-in check being proposed? Record the answer, assign the open questions and review the proposal before making a change.
For related context, see Q360’s managed technology services.
#ConditionalAccess #MicrosoftEntra #MFA #IdentityManagement #Q360