Set Microsoft Entra Sign-in Frequency and Browser Persistence

What do Microsoft Entra session controls actually do?

Sign-in frequency sets how long a user can access a resource before being required to authenticate again. It is not an idle timer: supported applications enforce it when they next evaluate the session or request access. Existing sessions do not necessarily end at the exact interval you set.

Persistent browser session controls whether a supported browser sign-in can survive closing and reopening the browser. Never persistent does not set an inactivity timeout, clear downloaded files or control every desktop and mobile app session. Application support, device sign-in and other policies can affect the experience.

How can regular re-authentication reduce risk?

Requiring fresh authentication can reduce reliance on long-lived sessions. Preventing browser persistence can also reduce the chance that someone reopens a shared browser and finds a business account still signed in.

These controls do not prove that the person signing in is the legitimate account holder. An attacker with usable credentials or a stolen session may still gain access. Combine them with phishing-resistant MFA, appropriate device controls, separate administrator accounts and a response process for compromised accounts.

For an Australian small business using shared reception computers or personal laptops, device security and explicit sign-out remain important. Session controls alone do not make a public computer safe for sensitive work.

What risks remain without a deliberate session policy?

Relying on default session behaviour may leave access available longer than your business intends, particularly on shared devices. However, having no custom sign-in frequency policy does not mean sessions never expire: Microsoft Entra defaults, application behaviour and other controls still apply.

Unauthorised mailbox access can expose customer information or support invoice fraud. If you suspect an account compromise, investigate promptly, revoke sessions and address compromised credentials or devices rather than waiting for a sign-in interval to expire. Session revocation also depends on application support and may not take effect everywhere immediately.

How do you configure and pilot session controls safely?

Start with a small group and a clear reason for each restriction. The example below targets devices that are not marked compliant; it does not assume every personal device is unmanaged or every company device is compliant.

1. Confirm Microsoft Entra ID P1 or higher for users in scope, and use the Conditional Access Administrator role to manage the policy.
2. Prepare and test at least two cloud-only emergency access accounts with strong phishing-resistant authentication; exclude them from the new policy and alert on their use.
3. Review existing policies and Security defaults. If replacing Security defaults, prepare equivalent baseline protections and coordinate the transition before enabling Conditional Access.
4. Go to Microsoft Entra admin center > Entra ID > Conditional Access > Policies > New policy; name the policy, select a pilot group under Users and explicitly exclude emergency access accounts.
5. Under Target resources, select All resources. For this device-scoped example, use Conditions > Filter for devices to exclude devices matching device.isCompliant -eq True; confirm that your compliance signals are reliable.
6. Under Session, select Sign-in frequency, choose Periodic reauthentication and enter your risk-based interval; select Persistent browser session and choose Never persistent.
7. Set Enable policy to Report-only, save it and review matching sign-ins and policy interactions; use the What If tool to check intended scope.
8. Switch the pilot policy to On, test re-authentication and browser reopening across supported apps, then expand gradually with a documented rollback plan.

Which Microsoft 365 licences include these controls?

Configuring sign-in frequency and persistent browser session through Conditional Access requires Microsoft Entra ID P1 or higher for each user covered by the policy. Microsoft 365 Business Premium, Microsoft 365 E3 and Microsoft 365 E5 include the required entitlement. Office 365 E3 is a different product and does not, by itself, include Entra ID P1.

Microsoft 365 Business Basic and Business Standard do not include Entra ID P1, but an appropriate add-on licence can provide it. Check your actual subscriptions rather than assuming the plan name tells the whole story. Risk-based Conditional Access features require additional entitlement, such as Entra ID P2.

For businesses without Conditional Access licensing, Security defaults provides foundational protections including MFA requirements and blocking legacy authentication. It does not provide configurable session controls. Security defaults and Conditional Access are alternative approaches: plan replacement protections before disabling Security defaults.

Which rollout mistakes should you avoid?

Do not select All users before testing with a pilot group. Keep at least two emergency access accounts, protect them separately and monitor their use. Excluding them from a session policy reduces policy-related lockout risk but does not guarantee access in every outage.

Do not assume Never persistent automatically targets unmanaged devices. Device scope must be configured separately, and a device that is not marked compliant is not necessarily unmanaged. Missing or unreliable device signals can produce unexpected results.

Do not use frequent prompts as a substitute for MFA or device security. Excessive prompts can disrupt work and encourage staff to approve requests without thinking. Multiple Conditional Access policies can also interact, so review the effective result rather than each policy in isolation.

Review automation that signs in using user accounts. User-based Conditional Access policies do not govern service principal sign-ins in the same way. Keep direct sign-in blocked for shared mailbox accounts; staff should normally access them through their own delegated accounts.

How do you verify the policy and prepare staff?

Open Microsoft Entra admin center > Entra ID > Monitoring & health > Sign-in logs. Inspect a relevant sign-in and review the Conditional Access results; for a policy still in Report-only mode, inspect its report-only results. A policy appearing in a log does not prove that every application has enforced the intended session behaviour.

During the enforced pilot, test browser closing and reopening, re-authentication after the configured interval, and access through Outlook and other business apps. Test devices inside and outside any exclusions. Device single sign-on may affect what users see, and re-authentication does not necessarily mean entering a password and completing a new MFA prompt every time.

Tell staff which devices and apps are affected, why the change is being made and where to report unexpected prompts. Remind them never to approve an authentication request they did not initiate. Expand the policy only when expected behaviour and key workflows have been confirmed.

How do session controls support a broader security audit?

During a Microsoft 365 security audit for Australian businesses, checking sign-in frequency and browser persistence is just one aspect of a comprehensive review. We also examine MFA coverage, separate administrator accounts, emergency access, legacy authentication and application consent policies.

We review domain email authentication, including SPF, DKIM and DMARC, as a separate layer of protection against domain spoofing. Those controls address a different risk from account and session security.

Session controls support broader cybersecurity controls. They alone do not establish compliance with the Privacy Act or the Notifiable Data Breaches scheme. Businesses covered by these obligations still need appropriate governance, safeguards and breach assessment and response processes.