ISM-1648 asks that privileged access, the administrator rights that can change how systems work and get around their security controls, is disabled once nobody has used it for 45 days. In practice that means checking every day when each privileged account or role was last used, switching off anything idle for 45 days, and validating the need again before it comes back. It is part of the Essential Eight at Maturity Levels Two and Three, and works alongside ISM-1647, which disables privileged access after 12 months unless someone revalidates it.
In plain English:
ISM-1648 applies at every classification ASD marks, from non-classified systems to TOP SECRET. ASD's Essential Eight Maturity Model has the matching requirement, "Privileged access to systems and applications is disabled after 45 days of inactivity", at Maturity Levels Two and Three, so it is part of any Essential Eight assessment at those levels.
Idle administrator accounts are targets nobody is watching. ASD's assessment guidance gives the reasoning: "privileged user accounts that have not been used within 45 days can indicate that they are no longer required. Rather than user accounts remaining active, and a possible target for malicious actors to exploit, inactive user accounts should be disabled" (ASD). Microsoft's alert for unused administrator roles makes the same point: "It's also easier for attackers to remain unnoticed in accounts that aren't actively being used" (Microsoft).
Privilege piles up. People change jobs, projects end and contractors move on, and the administrator rights they were given tend to stay behind. The same assessment guidance asks privileged users to revalidate their need regularly "to avoid users collecting privileges and access as they change roles throughout an organisation". The 45-day rule catches the access nobody remembered to remove.
45 days is a common line. The CIS Critical Security Controls, a widely used international baseline, set the same figure for every account: "Delete or disable any dormant accounts after a period of 45 days of inactivity, where supported" (CIS). ASD applies it to privileged access in ISM-1648 and to everyone else in ISM-1404.
Privileged access ends in four ways:
Four more make it work. ISM-1404 sets the same 45 days for unprivileged access. ISM-0445 gives each privileged person a dedicated privileged account, which is what makes inactivity measurable. ISM-1507 asks that requests for privileged access are validated when first made, and ISM-1509 that privileged access events are centrally logged, the record of when access was last used.
| Ask | Look at | Good looks like |
|---|---|---|
| Where does privileged access exist? | The inventory of privileged accounts and roles across the directory, cloud, infrastructure and applications | Every one listed with an owner, including providers' and non-human accounts |
| When was each one last used? | Last sign-in and last activation reports, and centrally collected logs (ISM-1509) | Within the last 45 days for everything still enabled |
| What happens on day 45? | The automated rule or scheduled job, its settings and run history | Runs at least daily, disables at 45 days, records each action |
| Is anything idle still enabled? | A fresh query by last use, including accounts never used | Nothing, apart from recorded exceptions |
| How does access come back? | Requests to re-enable access, with approvals | Each validated like a new request (ISM-1507) |
| What is left out? | The exceptions register | Each exception justified, approved, monitored and dated for review |
Privileged access lives outside the directory. Firewalls, hypervisors, backup consoles, databases and the admin panels of online services often have their own accounts. Bring them behind single sign-on where possible; otherwise send their logs to the central log store so the last use can be read.
Last-used dates are approximate. In Active Directory, inactivity reports usually read the lastLogonTimestamp attribute, which Microsoft documents is updated only "if this value is older than the current time minus the value of msDS-LogonTimeSyncInterval", initially "14 days minus random percentage of 5 days" (Microsoft), so it can be more than a week behind. In Microsoft Entra ID the last sign-in "might take up to 24 hours to update" and is blank for an account that "was never used for a sign-in attempt" (Microsoft). The same page suggests 90 to 180 days as a window for user accounts in general; privileged accounts need ASD's shorter 45. Never let a blank date count as active.
Accounts meant to sit idle. Break glass accounts wait for an emergency, and disabling one automatically could lock everyone out at the worst moment. Microsoft's guidance says an emergency access account's credential "must not expire or be in scope of automated cleanup due to lack of use", and that the accounts are checked "at least every 90 days" (Microsoft). ISM-1648 names no exception for them, unlike ASD's lockout control, ISM-1403. One way to reconcile the two: keep break glass accounts out of the automation, record that as an exception, and sign in with each as a planned, logged test at least every 45 days, which also proves it works. Our ISM-1685 guide covers protecting these accounts. Service accounts for quarterly or yearly jobs, and vendor support accounts, are best left disabled and switched on for a set window when needed.
Leave. An administrator back from parental or long service leave will find their access switched off. That is the control working; restore it through the normal request.
Managed service providers. A provider's technicians often hold administrator accounts in the organisation's tenant and on its devices. Ask which accounts they hold, when each was last used, and whether their process disables idle ones at 45 days.
Smaller and larger organisations. A smaller organisation usually has a handful of administrator accounts in one cloud identity platform, plus its provider's: dedicated accounts, a daily automated check and a page of documentation do most of the work. A larger one has privileged access across directories, clouds, infrastructure and hundreds of applications, so the work is an inventory, central sign-in or logging, and an identity governance process that runs every day.
The business case. The cost is mostly set-up time and some friction for occasional administrators. Some platforms offer just-in-time roles and automated reviews only in higher licence tiers. What it buys is fewer powerful accounts sitting unwatched, and one of the requirements for Essential Eight Maturity Level Two.
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-1648 among the other access controls, open it in our sample coverage report, or read what an ISM assessment involves.
ISM-1648 is not new: ASD's catalogue records it at revision 2, last updated in June 2025. That release reworded it and its neighbours "for clarity without changing their intent", and rescinded ISM-1716, "access to data repositories is disabled after 45 days of inactivity", "due to its duplication of recommendations within ISM-1404 (for unprivileged access) and ISM-1648 (for privileged access)" (ASD). Data repositories now sit inside the "systems and their resources" ISM-1648 names.
In September 2026, ISM-1648 and the other suspension and privileged access controls moved from "Guidelines for personnel security" to "Guidelines for system access › Identity and access management", with ISM-1648's wording unchanged. ISM-0430 and ISM-1591 now say "users" where they said "personnel", and ISM-0445 says "human users" (ASD). Our ISM September 2026 summary covers the rest.