Disabling Inactive Privileged Access to Systems
Access with special privileges is disabled if not used for 45 days to enhance system security.
Plain language
This control is about turning off special access rights to systems if they haven't been used in 45 days. It matters because people with special privileges can make big changes or access sensitive information. If their access isn't switched off when they're not using it, it could be a way for hackers to cause damage if those accounts get hacked.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
ML2, ML3
Guideline
Guidelines for personnel securityOfficial control statement
Privileged access to systems and their resources are disabled after 45 days of inactivity.
Why it matters
If inactive privileged access is not disabled after 45 days, dormant admin accounts can be hijacked to gain elevated access and compromise systems.
Operational notes
Run a weekly report of privileged account activity and automatically disable privileged access after 45 days of inactivity; alert owners at 30/40 days.
Implementation tips
- The IT team should review all accounts with special privileges every month. Make a list of any accounts that haven't been used in the last 45 days. This helps identify accounts that need to have their access turned off.
- System administrators should set up notifications to alert them when a privileged account reaches 30 days of inactivity. Use system tools or scripts to keep track of when each account was last used, so actions can be taken before reaching 45 days.
- Managers should work with the IT team to ensure there is a clear process for reactivating access. This includes a simple request form or process that employees can use if they need their privileges back after being disabled.
- The HR team should ensure that all employees understand the importance of using their privileged access regularly if needed, or reporting back when no longer required. Include this in onboarding and regular training sessions.
- Security officers should create and maintain a policy document stating how inactive privileged access will be handled. This should detail who is responsible for checking inactivity and the steps to disable access, helping everyone understand the procedure.
Audit / evidence tips
-
Aska report detailing privileged accounts and their last active dates
Goodis a record showing accounts with clear last-used dates and confirmation of deactivated status
-
Goodwill include routine alert creation and actions taken for inactive accounts
-
Aska reactivation request process document
Goodis a clear, concise document with step-by-step instructions
-
Goodincludes comprehensive coverage of the topic in onboarding and training
-
Askthe policy document related to disabling inactive privileged access
Goodis an organised document with detailed procedures and who is responsible at every stage
Cross-framework mappings
How ISM-1648 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex A 5.18 | ISM-1648 requires disabling privileged access after 45 days of inactivity as part of keeping access current and reducing unnecessary elev... | |
| Annex A 8.2 | ISM-1648 requires a specific administrative action: disabling privileged access after 45 days of inactivity | |
E8
| Control | Notes | Details |
|---|---|---|
| handshake Supports (1) expand_less | ||
| E8-RA-ML1.4 | E8-RA-ML1.4 requires that privileged accounts authorised for online services are strictly limited to what is needed for duties | |
| link Related (1) expand_less | ||
| E8-RA-ML2.2 | ISM-1648 requires privileged access to systems and their resources to be disabled after 45 days of inactivity | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.