<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Conditional-Access on Eriteach | Microsoft Cloud Tech</title><link>https://blog.eriteach.com/en/tags/conditional-access/</link><description>Recent content in Conditional-Access on Eriteach | Microsoft Cloud Tech</description><generator>Hugo -- 0.155.1</generator><language>en</language><copyright>2024-2026 Robel Mehari. All rights reserved.</copyright><lastBuildDate>Sat, 20 Jun 2026 23:23:39 +0200</lastBuildDate><atom:link href="https://blog.eriteach.com/en/tags/conditional-access/index.xml" rel="self" type="application/rss+xml"/><item><title>Stop Treating Remembered MFA Devices as a Security Strategy</title><link>https://blog.eriteach.com/en/posts/entra-mfa-remember-devices-session-controls/</link><pubDate>Sat, 20 Jun 2026 00:00:00 +0000</pubDate><guid>https://blog.eriteach.com/en/posts/entra-mfa-remember-devices-session-controls/</guid><description>Review remembered MFA devices in Microsoft Entra ID and move toward Conditional Access session controls for safer sign-in behavior.</description><content:encoded><![CDATA[<h2 id="the-problem">The Problem</h2>
<p>A small setting can quietly weaken a good MFA design.</p>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<blockquote>
<p>MFA prompt reduction should be controlled through Conditional Access session policy, not through old tenant-wide convenience habits.</p>
</blockquote>
<h2 id="environment">Environment</h2>
<p>This applies to Microsoft Entra ID tenants that use MFA and Conditional Access.</p>
<p>Typical environments affected by this are:</p>
<ul>
<li>hybrid or cloud-only Microsoft 365 tenants;</li>
<li>schools, municipalities, and distributed organizations;</li>
<li>users moving between managed and unmanaged devices;</li>
<li>admins trying to balance security with prompt fatigue.</li>
</ul>
<h2 id="what-i-checked">What I Checked</h2>
<p>The first thing I would check is whether the tenant still allows users to remember MFA on devices.</p>
<p>In Microsoft Entra admin center, review:</p>
<ol>
<li><strong>Protection</strong> &gt; <strong>Multifactor authentication</strong> &gt; <strong>Additional cloud-based multifactor authentication settings</strong>.</li>
<li>The setting for remembering multifactor authentication on trusted devices.</li>
<li>Conditional Access policies that already control sign-in frequency or persistent browser sessions.</li>
<li>Sign-in logs for repeated prompts, risky sign-ins, and unmanaged device usage.</li>
</ol>
<p>The important part is to avoid changing a user-facing authentication setting without first understanding where prompt reduction is already handled.</p>
<h2 id="the-decision">The Decision</h2>
<p>I would not treat remembered MFA devices as the main way to reduce prompts.</p>
<p>A better model is:</p>
<ul>
<li>use Conditional Access to decide when sessions should persist;</li>
<li>use sign-in frequency to decide when users must reauthenticate;</li>
<li>use device compliance or hybrid join where device trust matters;</li>
<li>use risk signals where available;</li>
<li>keep emergency access accounts outside normal user policies.</li>
</ul>
<p>This gives the admin more control than a broad remembered-device setting.</p>
<h2 id="the-fix">The Fix</h2>
<p>A safe rollout would look like this:</p>
<ol>
<li>Review the current MFA remember-device setting.</li>
<li>Identify affected users or groups.</li>
<li>Review existing Conditional Access session controls.</li>
<li>Create or adjust a Conditional Access policy for session lifetime.</li>
<li>Pilot with a small group.</li>
<li>Monitor sign-in logs and helpdesk feedback.</li>
<li>Disable remembered MFA on trusted devices if the Conditional Access policy covers the needed user experience.</li>
</ol>
<p>In Conditional Access, the two relevant controls are usually:</p>
<ul>
<li><strong>Sign-in frequency</strong> — how often the user must perform an interactive sign-in again.</li>
<li><strong>Persistent browser session</strong> — whether the browser session can remain persistent after closing and reopening the browser.</li>
</ul>
<h2 id="what-changed">What Changed</h2>
<p>The benefit is not that users get more prompts.</p>
<p>The benefit is that prompts become policy-driven.</p>
<p>Instead of relying on a remembered MFA checkbox, admins can say:</p>
<ul>
<li>managed devices can have a smoother experience;</li>
<li>unmanaged devices can be challenged more often;</li>
<li>risky sessions can be interrupted;</li>
<li>sensitive apps can have stricter session behavior;</li>
<li>changes can be scoped, piloted, and rolled back.</li>
</ul>
<p>That is easier to explain and easier to audit.</p>
<h2 id="what-to-watch-out-for">What to Watch Out For</h2>
<p>Do not disable remembered MFA globally without checking user impact.</p>
<p>Watch for:</p>
<ul>
<li>increased MFA prompts after the change;</li>
<li>shared-device scenarios;</li>
<li>browser session behavior in Edge, Chrome, and mobile apps;</li>
<li>break-glass account exclusions;</li>
<li>service accounts or legacy authentication dependencies;</li>
<li>conflicts between multiple Conditional Access policies.</li>
</ul>
<p>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.</p>
<h2 id="related-links">Related Links</h2>
<ul>
<li><a href="https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime">Configure authentication session management with Conditional Access</a></li>
<li><a href="https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-mfasettings">Configure Microsoft Entra multifactor authentication settings</a></li>
<li><a href="https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-howitworks">How Microsoft Entra multifactor authentication works</a></li>
</ul>
<h2 id="final-thought">Final Thought</h2>
<p>Remembered MFA devices are convenient, but convenience should not become the security model.</p>
<p>For most modern tenants, Conditional Access session controls are the cleaner place to manage this trade-off.</p>
]]></content:encoded></item></channel></rss>