ISM-0428 asks that the services people sign in to, such as email, file sharing, business applications, remote desktops and administration portals, lock a session after at most 15 minutes of inactivity, after at most 12 hours in total, and whenever the person chooses to lock it. A locked session hides everything in it, unlocking takes the full sign-in with every authentication factor, and nobody can switch the lock off for themselves. Its companion, ISM-2012, asks the same of the computer itself through a screen lock.

#What does ISM-0428 require?

ASD's statement has four parts. In plain English:

• When the session locks. After no more than 15 minutes in which the person does nothing in the service; after no more than 12 hours of overall session time, however busy they are; or straight away when they lock it themselves.
• What the lock does. It "blocks access to all session content": nothing in the session can be read or used until it is unlocked.
• How it unlocks. The person signs in again "using all authentication factors". If the first sign-in took a password and an authenticator app, unlocking takes both; a remembered browser or a password on its own is not enough.
• Who decides. People cannot turn the lock off. The limits are set centrally by whoever runs the service, not left to each person's preferences.

The control is about services rather than devices. In ASD's words, session locking "prevents unauthorised access to services that a human user has already authenticated to". That means webmail, document libraries, business applications, cloud administration consoles, and remote or virtual desktop sessions. Locking the computer in front of the person is a separate control, ISM-2012.

Since September 2026 the statement speaks of "human users" throughout. The lock is about people who sign in; the accounts that applications, workloads and AI agents use are handled by other controls. ISM-0428 applies at every classification ASD marks, from non-classified systems to TOP SECRET. It is not part of the Essential Eight.

#Why does it matter?

Sessions outlive the person at the keyboard. Someone signs in to email on a shared computer or a home PC, then walks away. Until the session ends, anyone who sits down has the mailbox, the files and anything else the account can reach. The screen lock on the organisation's own computers helps, but services are reached from devices the organisation does not manage, and the service's own lock is the one that works on all of them. Microsoft describes its idle timeout for web apps as protection "for end users who work on non-company or shared devices" (Microsoft).

A session that never ends can be stolen and reused. Browsers stay signed in by holding session cookies and tokens, and ASD warns that once someone has signed in, attackers may go after those instead of the password: "Adversary-in-the-middle phishing and information-stealing malware can capture these authentication artefacts and replay them to bypass authentication measures, including multi-factor authentication." A copied session is only useful while it is still valid, so the 12-hour limit caps how long a stolen session keeps working, provided the service enforces the limit on its own side (ISM-2066).

The numbers are not arbitrary. They match the strictest level of the United States' digital identity guideline, NIST SP 800-63B-4: "At AAL3, the overall timeout for reauthentication SHALL be no more than 12 hours. The inactivity timeout SHOULD be no more than 15 minutes" (NIST). NIST adds that at this level "reauthentication requirements are the same as for initial authentication", which is what ASD's "all authentication factors" asks for.

#How does it fit with the other controls?

ISM-0428 protects the service. The controls around it protect the device and deal with sessions that are stolen rather than left open:

• ISM-2012: computers get a screen lock with the same 15-minute limit. It hides the whole screen, must activate before the screen goes into power saving, takes every factor to unlock, and cannot be switched off by the person. ASD split it from ISM-0428 in March 2025.
• ISM-1888: phones and tablets have secure password-based lock screens.
• ISM-0853: interactive user sessions are ended and workstations restarted at least daily. ASD's reason is that this helps remove "malicious actors that may have compromised a system but failed to gain persistence".
• ISM-2066: web application sessions are managed centrally on the server, so the service, not the browser, decides when a session has expired and can end it.
• ISM-2147: tokens and session cookies are bound to the device they were issued on, so a copy taken elsewhere does not work.
• ISM-2148: sessions and tokens are revoked when credentials are reset or compromised, when a device stops meeting requirements, or when risky sign-in activity is detected.

Put simply: the screen lock covers the desk, the session lock covers the service wherever it is used from, and binding and revocation cover the session someone has already copied.

#How do you meet ISM-0428?

1. List the services people sign in to. The identity platform that provides single sign-on, email and files, business applications, remote access and virtual desktops, and every cloud or administration console. For each, note where its session settings live: in the identity platform, in the service itself, or both.
2. Set the overall limit to 12 hours or less. Where services sign people in through a central identity platform, its session lifetime or re-authentication setting does most of the work. Services that keep their own sessions need their own setting. Default settings can be far longer: Microsoft's default sign-in frequency is "a rolling window of 90 days" (Microsoft), and Google says "the web session length for Google services is 14 days" by default (Google).
3. Set the inactivity limit to 15 minutes or less in each service that offers one. Signing the person out after inactivity does the same job as a lock: the content is gone and getting back in takes a full sign-in.
4. Make unlocking a full sign-in. Test that re-authentication asks for every factor the first sign-in did, not only a password or a remembered device.
5. Take the choice away from users. Hide or turn off options that let people stay signed in indefinitely, such as a "Stay signed in?" prompt or browser sessions that persist after the browser closes, and set every limit by policy rather than personal preference.
6. Make locking by hand easy. Teach people to lock the screen or sign out when they step away; on managed computers the screen lock (ISM-2012) hides every open session at once.
7. Record the exceptions. Wall dashboards, control room consoles and long-running jobs sometimes cannot lock. Write each one down with the reason, the approver, what protects it instead (a read-only account, a locked room) and a review date.
8. Write the standard down and test it. A short session standard, the settings that implement it and a dated test result for each service are what an assessor will ask to see.

#What evidence shows ISM-0428 is met?

#What gets in the way?

Services differ. Some offer an overall session length but no inactivity timer, some time out the web version and not the desktop or mobile app, and some keep their own sessions after single sign-on. Read each vendor's documentation for what its setting covers. Microsoft, for example, lists the cases in which its idle session timeout does not sign people out (Microsoft). Where a service cannot lock itself, put it behind single sign-on with a short session if it allows that, and record the gap as an exception.

Friction and prompt fatigue. Frequent sign-in prompts annoy people, and they can train people to approve whatever appears. Microsoft puts it this way: "Users who habitually enter credentials without thinking might unintentionally provide them to malicious prompts" (Microsoft). The answer is not longer sessions but quicker sign-in. A passkey unlocked with a fingerprint, face or PIN takes a second, and ASD's glossary notes that a passkey "provides multi-factor authentication where use of the private key requires a separate activation factor, such as a password or biometric."

Shared and always-on screens. Reception desks, control rooms and operations dashboards are built to stay open. They belong on the exceptions register, with physical protection and the least access possible.

Smaller and larger organisations. A smaller organisation usually has one identity platform and a dozen or so services, so meeting ISM-0428 is mostly a few policy settings, a test and a page of documentation. A larger one has hundreds of applications, many with their own session handling, plus remote access gateways and legacy systems: the work is an inventory, moving applications behind single sign-on, and an exceptions process that is actually reviewed.

The business case. The cost is mostly configuration time and a little friction. What it buys is that a session left open, or copied by an attacker, stops being useful within minutes or hours instead of weeks.

#What tools and skills help?

• An identity platform with session controls, which sets one session lifetime and re-authentication rule across every application signed in through it. Microsoft's sign-in frequency "specifies how long a user can access a resource before being asked to sign in again" (Microsoft), and Okta's global session policy sets the idle time "that passes before Okta sessions are automatically expired, regardless of the maximum Okta session lifetime" (Okta).
• The services' own timeout settings. Microsoft 365's idle session timeout sets how long users can be inactive "before they're signed out of Microsoft 365 web apps" (Microsoft), and Google Workspace administrators can control "how long users can access Google services, such as Gmail on the web, without having to sign in again" (Google).
• Session limits on remote access and virtual desktops, set on the gateway or host.
• Device management, which enforces the screen lock on computers (ISM-2012) and phones (ISM-1888) so people cannot turn it off.
• Sign-in logs, to confirm that re-authentication happens when the policy says it should.
• Skills to work out how each service keeps its sessions, which setting wins when the identity platform and the application disagree, and how to test the result.

Which of your current licences already provide these? The free coverage check shows which ISM and Essential Eight controls the products you already pay for can reach, in about three minutes. To see ISM-0428 among the other access controls, open it in our sample coverage report, or read what an ISM assessment involves.

#What changed in recent ISM releases?

ISM-0428 is a long-standing control, reshaped recently. Until March 2025 it asked that systems have "a session or screen lock". In that release, ASD's summary of changes says the control "was amended to focus exclusively on session locking", adding the 12-hour overall limit and re-authentication with all factors, and the screen lock became a new control, ISM-2012 (ASD).

In the September 2026 release, ISM-0428 (now revision 11) and ISM-2012 moved from "Guidelines for system hardening › Authentication hardening" to "Guidelines for system access › Identity and access management", and both now say "human users" where they said "users". The limits did not change. The same release reworded ISM-0853 to "interactive user sessions" and added ISM-2147 and ISM-2148 on protecting and revoking sessions and tokens. Our ISM September 2026 summary covers the rest of that release.

#Sources

• ASD, Information security manual: ISM-0428, the screen locking, session termination and authentication artefact controls, and the section guidance quoted on this page
• ASD, ISM March 2025 changes: the split of session locking and screen locking
• NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management: reauthentication limits at AAL3
• Microsoft, Idle session timeout for Microsoft 365
• Microsoft, Conditional Access adaptive session lifetime policies
• Google, Set session length for Google services
• Okta, Add a global session policy rule