ISM-1648: Disable Idle Admin Access After 45 Days

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.

#What does ISM-1648 require?

In plain English:

• What it applies to. Any account or role that can change a system's settings or bypass its security controls. ASD says this "also applies to user accounts that may only have limited privileges but still have the ability to bypass some security controls." That takes in administrators of the directory and cloud tenant, servers, network devices, backup systems and databases, and the administrator side of each business application.
• What counts as inactivity. 45 days in which the privileged access has not been used. ASD's Essential Eight assessment guidance measures this by each privileged account's last sign-in. Where people hold an administrator role they switch on only when needed, the clock runs from the last time they switched it on.
• What disabled means. The access stops working: the account is disabled, or the administrator role is removed from it. Disabling is not deleting; the account and its history stay, and access can be restored once the need has been checked.
• Whose access it covers. People, and the accounts that services and applications use. ASD's introduction to identity and access management says that "security controls for identifying, authenticating, authorising and monitoring users also apply to non-human users, such as services, applications, workloads and artificial intelligence (AI) agents."

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.

#Why does it matter?

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.

#How does it fit with the other controls?

Privileged access ends in four ways:

• ISM-0430: access is removed or suspended the same day the need for it ends, such as when someone leaves or changes role.
• ISM-1591: access is removed or suspended as soon as practicable when a user is caught doing something malicious.
• ISM-1648: privileged access unused for 45 days is disabled, catching what the first two missed.
• ISM-1647: privileged access is disabled after 12 months unless revalidated, even if it is used every day.

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.

#How do you meet ISM-1648?

1. Find all privileged access: the directory and cloud identity platform, cloud consoles, servers, network and security devices, backup systems, databases and business applications. Include vendors' and providers' accounts, and privileged accounts used by services, scripts and AI agents. The directory's built-in administrator groups are a start, not the whole list.
2. Keep privileged accounts separate from everyday ones (ISM-0445). Administrator rights on someone's email account never look idle, because the account signs in every day. A dedicated account's last sign-in is the last use of the privileged access.
3. Decide where "last used" comes from for each system: the identity platform's last sign-in, the last activation of a just-in-time role, or centrally collected logs (ISM-1509) for systems with their own accounts. Count an account that has never been used from the day it was created.
4. Automate it. ASD's guidance favours removing access "ideally using an automatic mechanism", and its assessment guide asks for evidence that the check for inactive privileged accounts "takes place on a daily basis". Run it daily, disable at 45 days and log each action. A few weeks in report-only mode first shows up surprises.
5. Disable, do not delete. Removing access for good is for when the need has ended (ISM-0430), and a disabled account keeps its history for any later investigation.
6. Treat switching it back on as a new request (ISM-1507): who asked, why, who approved, and for how long.
7. Decide what happens to accounts meant to sit idle, such as break glass accounts and rarely used service accounts, and write it down.
8. Document and test. A short standard, the automation's settings and run history, and an exceptions register are what an assessor will ask to see.

#What evidence shows ISM-1648 is met?

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

#What gets in the way?

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.

#What tools and skills help?

• Sign-in reporting in the identity platform. Microsoft documents finding inactive accounts in Microsoft Entra ID from the last sign-in date (Microsoft), and Okta's automations look for "active users who haven't signed in to Okta for a set number of days" and can suspend them (Okta).
• Just-in-time privileged access, where administrators switch a role on only when needed. Microsoft's Privileged Identity Management can alert when "a user goes over a specified number of days without activating a role" and offers to remove it (Microsoft). Microsoft also notes there is "no difference in the access given to someone with a permanent versus an eligible role assignment" (Microsoft), so an unused eligible role still needs managing.
• Identity governance and access reviews, which run the 45-day rule beside the 12-month revalidation in ISM-1647 and record each decision.
• Unused access reports in cloud platforms. AWS's IAM Access Analyzer, for example, reports permissions that "show no usage" over a tracking period you choose (AWS).
• A privileged access management platform for servers, network devices and databases with their own accounts: it holds the credentials and records each use.
• Central logging, so privileged access events (ISM-1509) from every system can be searched for the last use.
• Skills to find privileged access wherever it lives, automate disabling safely, and run an exceptions process someone actually reviews.

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.

#What changed in recent ISM releases?

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.

#Sources

• ASD, Information security manual: ISM-1648, the suspension and privileged access controls, and the section guidance quoted on this page
• ASD, Essential Eight Maturity Model and Essential Eight assessment process guide: Restrict administrative privileges
• ASD, ISM June 2025 changes and ISM September 2026 changes
• CIS, CIS Controls Assessment Specification, Control 5: Safeguard 5.3, Disable Dormant Accounts
• Microsoft, How to manage inactive user accounts, Last-Logon-Timestamp attribute and Manage emergency access accounts
• Microsoft, What is Privileged Identity Management? and Security alerts for Microsoft Entra roles in PIM
• Okta, Add an automation; AWS, Create an IAM Access Analyzer unused access analyzer