ASD ISM 0428 Session lock timing, content blocking and full re-authentication for services
What it says
Services are configured with a session lock that: - activates after a maximum of 15 minutes of human user inactivity, a maximum of 12 hours of overall session time or when manually activated - blocks access to all session content - requires re-authentication by human users using all authentication factors to unlock the session - denies human users the ability to disable the session locking mechanism.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishServices must lock idle or long-running sessions, hide everything on screen, demand all authentication factors to unlock, and stop users from switching the lock off.
This control sets four rules for how a service locks a user's session. First, the lock has to kick in on its own. It must activate after no more than 15 minutes without any activity from the human user, after no more than 12 hours of total session time regardless of activity, or whenever the user chooses to lock it manually. Second, once locked, nothing from the session may be visible or reachable. The lock has to hide all session content, not just dim the screen or cover part of it. Third, getting back in has to be as strong as logging in. The user must re-authenticate with every authentication factor they normally use, not just a password or a quick PIN. Fourth, the user cannot turn the lock off. The locking mechanism is enforced by the service and is not a preference the user can disable. Why it matters: an unattended, unlocked session is an open door. Someone walking past a desk, a shared kiosk, or a lost device can read data, send messages or make changes as the legitimate user, with no credential theft required. A hard cap on session length also limits how long a stolen or hijacked session token stays useful. Requiring all factors to unlock stops a weak unlock path from undermining strong sign-in, and taking away the option to disable the lock stops the control from quietly evaporating through user convenience.
Free. Save your status, tasks and notes.
Why it matters
If services do not enforce this session lock, an unattended or abandoned session stays open and fully usable by anyone with physical or remote access to it, allowing them to read, alter or exfiltrate information under the real user's identity. Sessions with no overall time limit extend the window in which a hijacked session remains valid. A partial lock that still exposes content leaks information on screen, and an unlock that accepts fewer factors than sign-in gives an attacker a cheaper route past multi-factor authentication. If users can disable the lock, the control will be switched off by the people it most needs to protect, and the organisation will be unable to demonstrate compliance with the ISM requirement.
How to implement
Service owners inventory every service that provides a session to human users and document, per service, the setting that controls inactivity timeout, overall session duration, manual lock, content blocking, re-authentication and user-disable restrictions.
System administrators configure each service to lock automatically after no more than 15 minutes of human inactivity and after no more than 12 hours of overall session time, and verify by testing that background or automated traffic does not reset the inactivity timer.
Administrators enable a manual lock option in each service (for example a lock command, keyboard shortcut or menu item) and confirm it triggers the same full lock as the automatic timers.
Identity and access engineers configure the unlock flow so that it requires every authentication factor used at sign-in, removing any simplified unlock methods such as PIN-only or password-only, and test that the locked state hides all session content including notifications and background windows.
Security administrators enforce the session lock through central policy or server-side configuration, remove user-facing options that could disable or extend it, and add the settings to the build standard and change-control checklist so they are re-checked after every service update.
Keep it running
In practice this control lives in the configuration of each service that presents a session to a human user, so the day-to-day work is keeping those settings correct and consistent as services change.
- Maintain a register of in-scope services and, for each, record where the inactivity timeout, overall session limit, manual lock option, content-blocking behaviour, re-authentication requirement and user-disable restriction are configured.
- Treat the values as ceilings: 15 minutes inactivity and 12 hours overall session time are maximums, so shorter values are acceptable and may suit higher-risk services.
- Distinguish human inactivity from background activity. Automatic refreshes, polling or keep-alive traffic must not count as user activity or the inactivity lock will never trigger.
- The 12 hour cap applies to the whole session regardless of activity, so it needs a separate timer from the inactivity lock and must not be reset by user interaction.
- Confirm the unlock path uses all authentication factors. Services that offer a simplified unlock (PIN only, password only, biometric only) need that shortcut removed or reconfigured.
- Check that content is fully blocked when locked. Notification previews, background windows, cached page content or chat pop-ups that remain visible are gaps.
- Lock the settings down. Remove or disable any user-facing option, policy override or self-service preference that lets a user turn off or lengthen the lock, and monitor for configuration drift after updates.
- Include the session lock settings in change management and in the onboarding checklist for any new service, so the control is applied before go-live rather than retrofitted.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register or list of services in scope for this control and the configuration standard that applies to them.
Look at
Look at whether the standard explicitly sets a 15 minute (or shorter) inactivity lock, a 12 hour (or shorter) overall session limit, a manual lock option, full content blocking, full re-authentication and a prohibition on user disablement.
Good evidence
Good looks like a complete list of services each mapped to a written standard that covers all four elements of the statement, with no service left unassigned.
- Check 2 of 5What an auditor asks for
Ask for
Ask for exported configuration or policy settings from a sample of services showing the inactivity and overall session timers.
Look at
Look at the actual values in effect, whether they are enforced centrally or set locally, and whether the overall session limit runs independently of user activity.
Good evidence
Good looks like values at or below 15 minutes and 12 hours respectively, applied by policy rather than user preference, with evidence the overall timer is not reset by activity.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a demonstration or recorded test of the locked state on a sample of services.
Look at
Look at what remains visible or accessible once the lock engages, including notifications, previews, background windows and any cached content, and whether a manual lock produces the same state.
Good evidence
Good looks like a lock screen that hides all session content with nothing readable or clickable behind it, triggered by inactivity, by the overall time limit and by the manual lock alike.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the unlock flow configuration and a test showing how a user regains access to a locked session.
Look at
Look at which authentication factors are demanded at unlock compared with the factors demanded at initial sign-in, and whether any simplified unlock method exists.
Good evidence
Good looks like unlock requiring every factor used at sign-in, with no PIN-only, password-only or biometric-only shortcut available to the user.
- Check 5 of 5What an auditor asks for
Ask for
Ask to see the user-facing settings for the session lock and any policy that governs whether users can change them.
Look at
Look at whether a user can disable the lock, extend the timers beyond the limits or bypass the mechanism, and whether administrators monitor for drift after updates.
Good evidence
Good looks like settings that are greyed out or absent for users, enforced by central policy or server-side configuration, with periodic checks confirming they remain in place.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.15.
ISM-0428 requires services to enforce session locking after defined inactivity/maximum duration, fully block session content while locked, require re-authentication using all factors to resume, and prevent users disabling the lock. Annex A 5.15 (Access Control Policies and Procedures) requires establishing and implementing logical access rules and procedures, under which session timeout/lock rules, lock-screen content suppression, and re-authentication requirements would be specified and governed. ISM-0428 is therefore a prescriptive technical rule-set that would sit underneath and implement part of the broader policy/procedure framework required by Annex A 5.15.
This control partially meets A.8.5.
ISM-0428 requires re-authentication using all authentication factors to unlock a locked session, and prevents users from disabling the locking mechanism. This supports Annex A 8.5 by operationalising secure authentication procedures at the point of session unlock, ensuring authentication strength is maintained throughout the session lifecycle. Annex A 8.5 is broader (covering authentication technologies and procedures generally), whereas ISM-0428 is a specific use-case applying authentication controls to session re-entry.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.