A linked token is the paired elevated and filtered access token created for a user running with User Account Control. Windows uses it to separate the standard user context from the administrator context, so elevation can be requested without replacing the original logon session or account identity.
How Linked Tokens Work
A linked token is a Windows access-control pattern, not a separate account type. When User Account Control is in play, the system creates a filtered token for standard operations and a paired elevated token for administrative actions, allowing the same sign-in session to support both privilege levels without changing the underlying logon identity.
This design matters because the operating system can defer elevation until it is needed, while still preserving the original user context. In practice, the linked pair is part of Windows' privilege boundary management, where the standard token is used for everyday work and the elevated token is only activated for approved administrative tasks.
Because the two tokens are linked, a process launched in one context does not automatically inherit the other. That separation reduces accidental overreach, but it also means administrators need to understand which context an application, script, or management tool is actually running under when they troubleshoot access failures or unexpected prompts.
Why Linked Tokens Exist
Linked tokens are meant to balance usability and security. Without them, administrators would either work all day with full privilege or constantly switch accounts. The linked-token model lets Windows keep the user's normal desktop behavior intact while reserving elevation for changes that truly need it.
That separation also reduces the blast radius of routine activity. File browsing, email, and other non-administrative tasks run in the filtered context, which helps limit the chance that a mistake or malicious code can silently operate with higher privilege just because the logged-on user is an administrator.
In identity terms, the linked token preserves the original logon identity while changing the effective authorization context. The important nuance is that elevation does not create a new person or a new session, it changes the privileges attached to the existing session in a controlled way.
Where Linked Tokens Can Create Confusion
Linked tokens often surface in troubleshooting because the same user can appear to have two valid security contexts. A tool, installer, or management action may succeed from an elevated process and fail from a standard process, even though both belong to the same account. That difference is usually about token contents, not authentication.
Another common source of confusion is privilege inheritance. If an application starts unelevated, it generally stays in the filtered context unless explicitly relaunched with elevation. Likewise, administrative access obtained for one task does not automatically propagate to unrelated child processes in a safe or consistent way unless Windows permits that transition.
For defenders and operators, the practical takeaway is that linked-token behavior is a normal part of Windows privilege separation. It is not a bug by itself, but it can expose misconfigured expectations about what a user can do versus what a process can do.
Linked Tokens and Windows Privilege Boundaries
Linked tokens sit at the intersection of user convenience and privilege control. They support the broader principle of least privilege by letting standard activity remain low-privilege while still enabling just-in-time administrative elevation when required. That makes them central to how Windows implements UAC prompts and admin approval workflows.
They also help explain why some security controls are process-sensitive rather than account-sensitive. A single account can have a standard token, an elevated token, and different effective permissions depending on how the process was started and what consent path was taken.
For a deeper view of how Windows privilege boundaries and least-privilege models are treated in practice, see the NIST Cybersecurity Framework 2.0 for governance and protective control thinking, and the NIST SP 800-53 Rev 5 Security and Privacy Controls for access-control and privilege-management requirements.
Risk and Threat Considerations
Linked tokens matter to security because if an attacker reaches a process running with the elevated token, they may gain administrative capability without needing a separate credential prompt. The danger is not the concept itself, but the trust gap between standard and elevated contexts when malware, malicious scripts, or abused admin tools can cross that boundary.
Failure mechanism: Privilege separation fails when elevated processes are abused, stolen tokens are replayed, or users approve elevation for untrusted software, turning a normal UAC workflow into a privilege-escalation path.
Impact: The result can be local administrative compromise, broader system tampering, credential exposure from privileged memory or tools, and faster lateral movement once a high-privilege foothold is obtained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Linked tokens govern effective access by separating standard and elevated privilege contexts. |
| Recommendation — Apply PR.AA-05 to enforce least-privilege elevation and separate standard from administrative access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Linked-token elevation depends on protected credential and session handling around privileged access. |
| AC-6 — Least Privilege | The linked-token model exists to restrict routine activity to the filtered privilege set. | |
| Recommendation — Manage privileged credentials and session material so elevation cannot be abused or reused. Limit routine execution to the least privilege needed and reserve elevation for approved tasks. | ||
| MITRE ATT&CK | T1548 — Abuse Elevation Control Mechanism | UAC-linked tokens are part of the Windows elevation path attackers may try to abuse. |
| Recommendation — Map UAC abuse attempts to T1548 and hunt for suspicious elevation requests or privilege escalation. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Linked tokens affect how Windows users receive and use elevated access rights. |
| Recommendation — Review and remove unnecessary administrative access paths that rely on elevation prompts. | ||
Practitioner Guidance
What to watch for: Treat linked-token behavior as a signal that effective access depends on process context, not just account membership. When troubleshooting or hardening Windows endpoints, verify whether a task is failing because it is running under the filtered token, then confirm that elevation is actually required before changing policy or permissions.
Governance implication: Administrators should understand which users are allowed to elevate, which applications should prompt, and which workflows should be designed to avoid routine elevation altogether. The control objective is to keep standard work standard and make elevation intentional, visible, and limited.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org