A unique, immutable identifier for security principals such as users, groups, or computers in Windows operating systems. This design ensures that security attributes remain consistent even if the principal’s name changes. Windows generates a SID for each account upon creation, using it instead of the account name to control resource access. Names can change or be reused, but the SID remains constant and unique, providing a reliable basis for security decisions.
How a SID Is Structured
A SID is a variable-length string composed of several parts, typically written as S-1-5-21-3623811015-3361044348-30300820-1013. Reading left to right, it begins with a literal S indicating it is a SID, followed by a revision level, an identifier authority, and one or more subauthority values. The final segment, the relative identifier (RID), distinguishes one principal from another within the same domain or machine. The portion preceding the RID identifies the domain or local computer, so accounts from the same source share that prefix and differ only in their RID.
- Identifier authority: The entity that issued the SID, such as the NT Authority.
Well-Known SIDs
Some SIDs are standardized across every Windows system, allowing built-in identities to be referenced consistently. These well-known SIDs represent generic principals like Everyone (S-1-1-0), Local System, Administrators, and Authenticated Users. Because they are identical across all machines, software and administrators can rely on them regardless of the specific environment. Certain RIDs are also reserved, for example, the built-in Administrator account always carries a RID of 500.
How SIDs Are Used
SIDs are the identities that access control mechanisms actually operate on. When an Access Control Entry (ACE) grants or denies permissions, it references the subject by SID, not by username. At login, Windows creates an access token that includes the user’s SID and the SIDs of every group they belong to. Each time the user attempts to access a resource, the system compares the SIDs in the token against those listed in the resource’s security descriptor to determine whether access is allowed. This indirection is why renaming a user account doesn’t break its permissions, the underlying SID, and therefore its access, remains intact.
Why SIDs Matter
Using SIDs instead of names prevents a class of security problems. Because a SID is never reused, deleting an account and later creating a new one with the same name produces a different SID, so the new account does not silently inherit the old account’s access. This uniqueness is essential for accurate auditing, reliable permission assignment, and the prevention of privilege escalation through name collisions. It also means that copying or migrating accounts between domains requires deliberate handling, since a principal’s SID is tied to the domain that issued it. Understanding SIDs is therefore fundamental to troubleshooting Windows permissions, managing domain migrations, and reading security logs, where events are frequently recorded against SIDs rather than friendly account names.