A small setting can quietly weaken a good MFA design.

In Microsoft Entra ID, many tenants still have users who can remember multifactor authentication on a trusted device. The idea is understandable: fewer prompts, less friction, fewer helpdesk tickets.

But from an admin point of view, this is not really a device trust model. It is a session convenience feature. If the device is shared, unmanaged, stolen, or used from a risky context, the remembered MFA state can reduce the value of the next sign-in challenge.

The LinkedIn link I checked pointed to an article about disabling remembered MFA on trusted devices. The topic is worth writing about, but the stronger engineering lesson is this:

MFA prompt reduction should be controlled through Conditional Access session policy, not through old tenant-wide convenience habits.

Environment

This applies to Microsoft Entra ID tenants that use MFA and Conditional Access.

Typical environments affected by this are:

• hybrid or cloud-only Microsoft 365 tenants;
• schools, municipalities, and distributed organizations;
• users moving between managed and unmanaged devices;
• admins trying to balance security with prompt fatigue.

What I Checked

The first thing I would check is whether the tenant still allows users to remember MFA on devices.

In Microsoft Entra admin center, review:

1. Protection > Multifactor authentication > Additional cloud-based multifactor authentication settings.
2. The setting for remembering multifactor authentication on trusted devices.
3. Conditional Access policies that already control sign-in frequency or persistent browser sessions.
4. Sign-in logs for repeated prompts, risky sign-ins, and unmanaged device usage.

The important part is to avoid changing a user-facing authentication setting without first understanding where prompt reduction is already handled.

The Decision

I would not treat remembered MFA devices as the main way to reduce prompts.

A better model is:

• use Conditional Access to decide when sessions should persist;
• use sign-in frequency to decide when users must reauthenticate;
• use device compliance or hybrid join where device trust matters;
• use risk signals where available;
• keep emergency access accounts outside normal user policies.

This gives the admin more control than a broad remembered-device setting.

The Fix

A safe rollout would look like this:

1. Review the current MFA remember-device setting.
2. Identify affected users or groups.
3. Review existing Conditional Access session controls.
4. Create or adjust a Conditional Access policy for session lifetime.
5. Pilot with a small group.
6. Monitor sign-in logs and helpdesk feedback.
7. Disable remembered MFA on trusted devices if the Conditional Access policy covers the needed user experience.

In Conditional Access, the two relevant controls are usually:

• Sign-in frequency — how often the user must perform an interactive sign-in again.
• Persistent browser session — whether the browser session can remain persistent after closing and reopening the browser.

What Changed

The benefit is not that users get more prompts.

The benefit is that prompts become policy-driven.

Instead of relying on a remembered MFA checkbox, admins can say:

• managed devices can have a smoother experience;
• unmanaged devices can be challenged more often;
• risky sessions can be interrupted;
• sensitive apps can have stricter session behavior;
• changes can be scoped, piloted, and rolled back.

That is easier to explain and easier to audit.

What to Watch Out For

Do not disable remembered MFA globally without checking user impact.

Watch for:

• increased MFA prompts after the change;
• shared-device scenarios;
• browser session behavior in Edge, Chrome, and mobile apps;
• break-glass account exclusions;
• service accounts or legacy authentication dependencies;
• conflicts between multiple Conditional Access policies.

Also remember that this is not a replacement for device compliance. If the security decision depends on whether the device is managed, use device state in Conditional Access.

Related Links

• Configure authentication session management with Conditional Access
• Configure Microsoft Entra multifactor authentication settings
• How Microsoft Entra multifactor authentication works

Final Thought

Remembered MFA devices are convenient, but convenience should not become the security model.

For most modern tenants, Conditional Access session controls are the cleaner place to manage this trade-off.

Microsoft updated the Microsoft Entra What’s new page for June 2026 with a useful identity change: registration campaigns now support passkeys (FIDO2) as an authentication method.

The practical meaning is simple. Admins can use a registration campaign to nudge users during sign-in to register a passkey, instead of relying only on email reminders, helpdesk instructions, or one-off rollout communication.

Microsoft describes this as General Availability. The first rollout experience is optimized for users who are in a passkey profile without restrictions.

Why admins should care

Passkeys are one of the cleaner paths toward phishing-resistant authentication in Microsoft Entra ID. The hard part is not only enabling the method. The hard part is getting real users to register it at scale without turning the rollout into manual chasing.

This change moves part of that adoption work into the sign-in flow.

For many Microsoft 365 environments, that is useful because passkey projects often get stuck between three teams:

• identity admins enable the method
• endpoint teams handle platform readiness
• service desk handles user guidance and exceptions

A registration campaign does not remove the need for planning, but it gives admins a more controlled way to push adoption once the prerequisites are ready.

What I would check first

I would not turn this on broadly before checking the basics.

First, go to Microsoft Entra admin center > Protection > Authentication methods and review the passkey / FIDO2 configuration. Confirm who is in scope, whether restrictions are configured, and whether the target users are actually ready to register.

Then check the registration campaign configuration under the authentication methods experience. The key question is not only “can users register?”. It is “which users should be nudged now, and which users need a different path?”

For a first rollout, I would start with a pilot group that represents normal users, shared-device users if relevant, and a few support staff. That gives better feedback than testing only with admins.

Practical rollout / validation steps

A safe rollout pattern would look like this:

1. Confirm passkey / FIDO2 is enabled for a small pilot group.
2. Confirm the users are in a passkey profile that matches Microsoft’s current registration campaign behavior.
3. Enable the registration campaign for the pilot group.
4. Ask pilot users to sign in normally and document the registration prompt experience.
5. Validate successful registration in the user’s authentication methods.
6. Review sign-in logs and support tickets for friction before expanding.
7. Expand by department, location, or user type instead of enabling everyone at once.

What I like about this change is that it supports a measured rollout. It does not force admins to make passkeys a big-bang project.

Watch-outs

The Microsoft note says the first rollout experience is optimized for users in a passkey profile without restrictions. If your passkey configuration uses restrictions, test carefully before assuming the same user experience.

Also, registration is not the same as enforcement. A campaign can help users register passkeys, but Conditional Access and authentication strength policies still decide where phishing-resistant authentication is required.

I would also prepare a short helpdesk note before expanding. Users may ask what a passkey is, whether they need a phone, whether Windows Hello is involved, and what to do if registration fails.

Official Microsoft sources

• What’s new in Microsoft Entra
• Nudge users to set up Microsoft Authenticator using registration campaign
• Passkeys in Microsoft Entra ID