Skip to main content
Identity Authority
Category: Directory Services

Security Identifier

Also known as: SID, Windows Security Identifier
Simply put

A Security Identifier (SID) is a unique code that Windows systems use to identify a user account, group, or other security principal. Rather than relying on names, which can be changed or reused, Windows uses the SID to consistently recognize an entity behind the scenes. Each account is assigned its own SID, which typically does not change over the life of that account.

Formal definition

A SID is a unique, variable-length value used to identify a security principal (such as a user account, group, or other trustee) within the Windows NT family of operating systems and Active Directory. In most deployments the SID is issued by an authority (for example, a local system or domain) when the principal is created, and it is treated as immutable for the lifetime of that principal, allowing the underlying identity to remain stable even if the display name changes. SIDs are primarily an identification mechanism in Windows environments; access decisions typically reference SIDs (for example, in access control entries), but the SID itself represents identity rather than performing authentication or defining authorization policy. Scope note: this term is specific to Windows/Active Directory and is distinct from cross-platform identifiers used in other directory or federation contexts.

Why it matters

The SID is the stable anchor that Windows and Active Directory use to recognize a security principal regardless of how its display name or account name changes over time. This matters because names are mutable and reusable: a user could be renamed, or an old account name could be reassigned to a different person. Because access control entries reference the SID rather than the name, the underlying identity remains consistent, and permissions granted to a principal continue to resolve to the correct entity even after cosmetic changes. Conflating the name with the identity is a common source of misunderstanding, and the SID is precisely the mechanism that keeps identification distinct from the human-readable label.

Understanding SIDs is also important because the SID is an identification mechanism, not an authentication or authorization mechanism. A SID does not verify that a principal is who it claims to be, nor does it by itself define what that principal may do; it simply names the identity that authentication establishes and that authorization decisions reference. In most Windows deployments, access decisions are made by comparing SIDs present in a user's access token against SIDs listed in access control entries. Practitioners who treat the SID as a policy object rather than as an identifier can misdiagnose access issues that actually stem from token contents, group membership, or the access control configuration.

Because SIDs are typically immutable for the lifetime of a principal, they carry operational and audit significance: they persist in access control lists, in security logs, and in objects that outlive the account itself. This can produce so-called orphaned or unresolved SIDs when a principal is deleted, and it means that reviewing raw SIDs is sometimes necessary during forensic, migration, or troubleshooting work when name resolution is unavailable or misleading.

Who it's relevant to

Windows and Active Directory administrators
Administrators managing accounts, groups, and permissions rely on SIDs to understand why access resolves the way it does, since access control entries reference SIDs rather than names. Recognizing that a renamed account keeps the same SID, and that a deleted account may leave unresolved SIDs behind in access control lists, is essential for accurate permission management and cleanup.
Security and forensic analysts
Analysts investigating events in Windows environments encounter SIDs in security logs and object metadata, sometimes without corresponding names when accounts have been deleted or when name resolution is unavailable. Because the SID is the immutable identifier of the principal, it can be a more reliable pivot for correlating activity than a mutable display name.
IAM and migration engineers
Engineers performing domain migrations, consolidations, or identity integrations need to account for the scoped and immutable nature of SIDs, since a principal moved between authorities may receive a new SID while historical access control entries still reference the old one. Understanding that the SID represents identity, not authentication or authorization policy, helps in planning how access is preserved or reissued.
Auditors and compliance reviewers
Reviewers assessing access in Windows/Active Directory deployments benefit from understanding that SIDs are the stable underlying identifiers behind access grants. This is useful when verifying that permissions map to the intended principals and when interpreting entries that reference SIDs whose associated names may have changed or no longer resolve.

Inside SID

Revision level
A version number at the start of the SID structure indicating the revision of the SID format. In most Windows implementations this has remained a stable value across deployments.
Identifier authority
A value identifying the authority that issued the SID, such as the built-in local authority or the NT authority. It establishes the top-level namespace under which the remaining components are interpreted.
Subauthorities (relative components)
A sequence of values that identify domains, machines, or issuing entities within the identifier authority's namespace. Together with the RID they make the SID unique within its scope.
Relative Identifier (RID)
The final subauthority value that distinguishes a specific principal (user, group, or computer account) within the domain or local authority. Well-known RIDs identify built-in accounts and groups in typical deployments.
Canonical string form
The human-readable representation, conventionally rendered as S-<revision>-<identifier authority>-<subauthorities>, used when a SID is displayed or logged.

Common questions

Answers to the questions practitioners most commonly ask about SID.

Is a SID the same thing as a username or account name?
No. A username or account name is a human-readable identifier, while a SID is the immutable, machine-level identifier that the system actually uses to represent a security principal in access control decisions. Account names can be renamed without affecting the underlying SID, and permissions are typically bound to the SID rather than the name. This separation is why renaming an account generally does not break its existing access.
Does a SID authenticate a user or determine what they are allowed to do?
A SID does neither on its own. It is an identifier used to represent a security principal, so it belongs to the identification step, not to authentication (verifying who the principal is) or authorization (determining what the principal may do). Authentication is handled by credential validation, and authorization decisions reference SIDs, for example when comparing the SIDs in a user's access token against those in a resource's access control list, but the SID itself is just the identifier that makes those later steps possible.
What happens to permissions when an account is deleted and a new account is created with the same name?
Because a newly created principal typically receives a new, unique SID rather than the deleted account's SID, the recreated account does not inherit the prior account's access. Access control entries still reference the old SID, which now resolves to an unresolved or 'orphaned' SID on affected resources. In most deployments this means permissions must be re-granted explicitly, and administrators may see unresolved SIDs in access control lists until they are cleaned up or remapped.
How should SIDs be handled when migrating principals between domains?
When a principal moves to a new domain it typically receives a new SID scoped to that domain. To preserve access to resources still referencing the original SID, migration tooling often populates a SID history attribute so the old SID travels with the principal as a secondary identifier during authorization checks. SID history is generally intended as a transitional aid; many organizations plan to remediate resource permissions to the new SID and remove SID history afterward, since retained SID history can carry security considerations. Specific behavior depends on the directory platform and migration tooling, which are out of scope here.
Why do some SIDs appear identical across different systems while others are unique per environment?
Certain SIDs are well-known and constant by design so that standard groups and roles can be referenced consistently, while account and group SIDs are typically constructed to be unique within their issuing authority's scope. When you encounter a SID that looks the same everywhere, it is generally a well-known SID; when you encounter one unique to an environment, it was issued by that environment's authority. Whether a given SID is well-known depends on the platform's defined set, which you should verify against vendor documentation rather than assume.
How do SIDs relate to entries in an access control list during an access decision?
During a runtime access check, the enforcement point typically compares the SIDs present in the requesting principal's access token, including its own SID and the SIDs of groups it belongs to, against the SIDs recorded in each access control entry on the target resource. A match to an allow or deny entry drives the resulting decision. This makes accurate SID resolution important: unresolved SIDs in a list can produce unexpected results, and stale group SIDs in a token can affect what access is granted until the token is refreshed. Exact evaluation order and semantics vary by platform.

Common misconceptions

A SID authenticates a user or proves who the principal is.
A SID is an identifier used to reference a security principal; it does not perform authentication. Verifying who a principal is (authentication) and referencing that principal (identification via the SID) are distinct steps, and authorization decisions that consult a SID occur separately after authentication succeeds.
A SID directly grants permissions or defines what a principal can do.
A SID is an identity reference. Authorization is determined by comparing SIDs present in a principal's access token against access control entries; the SID itself carries no permissions. This reflects the general separation between identifying a principal and authorizing that principal's actions.
SIDs are globally unique and safe to reuse or reassign like usernames.
In typical Windows deployments SIDs are intended to be unique within their issuing scope and are generally not reused, so that a deleted account's SID is not reassigned to a new principal. Behavior can vary depending on how domains, machines, and cloning are handled in a given environment.

Best practices

Treat the SID as an identifier only, and keep authentication, identification, and authorization as separate steps when reasoning about access flows that reference SIDs.
Base access control decisions on SID membership in access tokens rather than on account names, which can change while the SID typically remains stable.
Avoid assumptions of SID reuse; when accounts are deleted and recreated, expect a new SID and reconcile any stale SID references left in access control entries.
Watch for orphaned or unresolved SIDs during access reviews and governance certifications, and treat them as candidates for cleanup as part of IGA lifecycle management rather than runtime enforcement.
When cloning machines or migrating domains, verify that SID generation and any SID history handling behave as expected for your environment, since behavior varies by tooling and configuration.
Reference well-known SIDs and RIDs by their documented meanings rather than hard-coding assumptions, and confirm values against authoritative platform documentation when precision matters.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.