Prevent Usage of sIDHistory in User Accounts
Ensure user accounts do not use the sIDHistory attribute for security purposes.
Plain language
The sIDHistory is a technical feature in computer systems that helps during migrations by retaining old permissions. However, keeping it can become a backdoor for hackers. If we don't switch this off, unauthorised people might sneak into secure areas of our systems, leading to data breaches or disruptions.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Aug 2024
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
Server application hardeningOfficial control statement
The sIDHistory attribute for user accounts is not used.
Why it matters
If sIDHistory is populated, attackers can abuse inherited legacy SIDs to escalate access and access data, leading to unauthorised changes, data breaches and service disruption.
Operational notes
After migrations, verify sIDHistory is blank on all user accounts and enforce a process to prevent future population. Monitor AD changes and periodically report any non-empty sIDHistory values.
Implementation tips
- The IT team should review all user accounts on the system. They need to check if any account uses the sIDHistory attribute, which is a way of carrying over old permissions. They can do this by using administrative tools specific to Microsoft Active Directory to list all attributes of user accounts.
- System administrators should remove the sIDHistory from accounts that no longer need it. This means carefully evaluating each account and using the Active Directory Users and Computers tool to delete the sIDHistory attribute where it's present.
- Managers should ensure that system migrations are thoroughly planned to avoid the need for sIDHistory. During migration planning meetings, discuss how to handle permissions without relying on sIDHistory and document the process in migration plans.
- HR and IT should coordinate to update user account permissions when employees change roles or leave the organisation. Ensure that staff are aware of the importance of updating accounts instantly to avoid relying on outdated sIDHistory settings.
- Security teams should conduct regular security audits to check for sIDHistory usage. This involves scheduling routine checks every six months using scripts or software to automatically flag accounts using sIDHistory and report them for review.
Audit / evidence tips
-
Aska recent user account audit report: Request documentation that lists all user accounts and any usage of the sIDHistory attribute
Goodis a dated report with no accounts showing active sIDHistory attributes
-
Askevidence of account migration plans: Request to see documented plans from recent system migrations
Goodincludes a detailed plan with steps and alternatives used instead of sIDHistory
-
Goodwould show an active tool in place with recent checks logged
-
Askthe policy on roles and permissions update: Request the organisational policy that outlines roles and permissions management. Ensure it specifies that sIDHistory should not be used and outlines steps taken upon role changes
Goodis a clear, written policy specifically prohibiting sIDHistory use
-
Askrecords of training sessions on this topic: Request evidence of staff training on the importance of managing sIDHistory appropriately
Goodincludes records of recent sessions with clear emphasis on the risks of sIDHistory
Cross-framework mappings
How ISM-1936 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (4) expand_less | ||
| Annex A 5.15 | ISM-1936 addresses a specific logical access control weakness by requiring organisations not to use the sIDHistory attribute on user acco... | |
| Annex A 5.18 | ISM-1936 requires that the sIDHistory attribute is not used on user accounts, which prevents legacy or migrated identifiers from being le... | |
| Annex A 8.2 | ISM-1936 requires that Active Directory user accounts do not use the sIDHistory attribute, reducing the risk of unintended or covert priv... | |
| Annex A 8.3 | ISM-1936 requires that sIDHistory is not used for user accounts, which helps prevent access being granted through historical identifiers ... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.