M1026 Privileged Account Management: Privileged Account Management Mapped to the Techniques It Stops

Most intrusions that become disasters pass through a privileged account, and ATT&CK reflects that: M1026 Privileged Account Management is mapped to more techniques than any other mitigation except M1018 User Account Management. In ATT&CK Enterprise v20, M1026 has 115 technique and sub-technique relationships across ten tactics, from credential dumping and Kerberos ticket forgery to container escape, cloud run commands and prompt injection against AI agents. This guide reads that mapping as a control plan: which techniques matter most, what ATT&CK actually asks you to do for each, how to implement it for human administrators and for service accounts, workload identities and agents, and how to measure coverage. It is for identity, PAM and detection engineering teams. Programme design, vendor selection and vaulting mechanics are in the Privileged Access Management Guide; this page stays on the ATT&CK view.

Key takeaways

• Broad mapping, few core actions. Nearly all 115 usage texts reduce to five instructions: fewer privileged accounts, no privileged accounts for daily work, no credential overlap across systems, least privilege for service accounts, and regular review of privileged assignments.
• Persistence and privilege escalation dominate. 37 of the relationships fall under Persistence and 31 under Privilege Escalation, followed by 27 under Credential Access: M1026 limits what a stolen credential can do next.
• Three techniques rely on M1026 alone. T1056.003 Web Portal Capture, T1555.006 Cloud Secrets Management Stores and T1651 Cloud Administration Command have no other mitigation in ATT&CK v20.
• Service accounts are named explicitly. ATT&CK tells you not to create service accounts with administrative privileges and to keep them out of groups such as Domain Admins, which is the core of Kerberoasting and Silver Ticket defence.
• AI agents are now in scope. v20 maps M1026 to T1698 Indirect Prompt Injection, T1699 Direct Prompt Injection and T1685.007 Impair Autonomous Defenses: agents must not exercise privileged permissions only because content told them to.

What the control is

ATT&CK defines M1026 as managing the creation, modification, use and permissions of privileged accounts such as SYSTEM, root and administrative accounts: restricting access, limiting the scope of permissions, monitoring privileged use and ensuring accountability through logging. Its implementation list covers role-based access and least privilege, credential vaulting and rotation, MFA for all privileged accounts, privileged access management tooling, SIEM monitoring of privileged activity and just-in-time elevation with time-limited roles. The ATT&CK text names products as examples; this guide stays vendor-neutral.

The distinction from neighbouring mitigations matters when you map coverage. M1018 User Account Management is about accounts in general; M1026 is specifically about accounts that can change the system or other accounts. M1036 Account Use Policies covers lockout and logon restrictions, M1032 covers MFA, and M1027 covers the passwords themselves. Many techniques list several of these together.

Techniques ATT&CK says M1026 mitigates

All counts below are computed from the ATT&CK Enterprise v20 STIX data: 115 active relationships, excluding revoked and deprecated objects. A technique with several tactics is counted once per tactic in the tactic totals.

The 20 that matter most

The selection below favours techniques that lead to domain or tenant control, or where ATT&CK gives M1026 a concrete instruction rather than a generic one. The guidance column paraphrases ATT&CK's own usage text.

For technique depth see the T1003 OS Credential Dumping, MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide, MITRE ATT&CK T1078 Valid Accounts Guide, MITRE ATT&CK T1098 Account Manipulation Guide, MITRE ATT&CK T1134 Access Token Manipulation, MITRE ATT&CK T1484 Domain or Tenant Policy Modification Guide and T1611 Escape to Host Defensive Guide.

Implementing M1026 across the estate

Microsoft's enterprise access model is a practical way to organise the work. It replaces the old Active Directory tier 0, 1 and 2 model with a control plane (centralised identity systems), a management plane (IT management of workloads and infrastructure) and a data and workload plane, plus user, application and privileged access pathways. Each plane controls the planes below it, so a lower plane must never be able to control a higher one.

1. Inventory every privileged identity. Human admin accounts, built-in accounts, local administrators, service accounts with group memberships that grant admin rights, cloud roles, Kubernetes cluster roles, CI/CD deployment credentials and AI agent tool credentials. See How to find service accounts with Domain Admin rights.
2. Separate accounts by plane. Dedicated admin accounts with no mailbox or browsing, distinct accounts for control plane and management plane work, and cloud-only accounts for cloud administration. Microsoft states that no on-premises account should hold administrative privileges in Microsoft 365.
3. Remove standing privilege. Move eligible roles to just-in-time activation with time-bound assignment, MFA on activation, justification and, for the highest roles, approval. Entra PIM documents these features; equivalent capabilities exist in other cloud and PAM platforms. See the JIT Access Guide.
4. End credential overlap. Unique local administrator passwords per host (see the Local Administrator Password Solution (LAPS) Guide), deny network logon for local accounts, and restrict which admin accounts can log on to which tier.
5. Fix service accounts. Remove them from Domain Admins and other privileged groups, use managed service accounts where possible, vault and rotate the rest, and block interactive logon.
6. Protect the admin path. Privileged access workstations for control plane work; ATT&CK specifically asks for AD FS access only from them. See the Privileged Access Workstations Guide.
7. Monitor and review. Alert on assignments outside the JIT process, on new members of privileged groups and roles, and on emergency access account use; review privileged assignments at least quarterly.

Testing and rollback: remove standing rights in rings, starting with the accounts with the most rights and the fewest daily users. Keep tested break-glass accounts so a failed JIT or PAM platform does not lock out administration (see the Break-Glass Account Guide). Rollback is re-granting a time-limited direct assignment with an expiry, never a permanent one.

Where identity fits: service accounts, workloads and agents

• Service accounts: ATT&CK's usage text for T1190 and T1210 says least privilege for service accounts limits what an exploited process can do. A web application pool running as a domain admin turns one vulnerability into domain compromise. See the Service Account Security Guide and the Kerberoasting and AS-REP Roasting Defence Guide.
• Cloud secrets and workload identities: T1555.006 depends entirely on who can read the secrets manager. Scope each workload identity to the secrets it uses. See the Secrets Management Guide.
• Kubernetes: disable service account token mounting for pods that do not call the API, and avoid cluster-admin bindings for workloads (T1552.007, T1609, T1611).
• AI agents: for T1698, T1699 and T1685.007, ATT&CK asks for independent authorisation or human approval before agents use administrative functions, privileged tools or sensitive resources. The PocketOS database deletion shows the failure mode: a coding agent found an account-scoped platform token created for domain management and used it to delete a production volume and its backups in one call. See the Human-in-the-Loop for AI Agents Guide and the AI Agent Authorisation Guide.

What M1026 does not stop

• Abuse of rights that are correctly assigned: an attacker with a legitimate admin session can still act. Approval for bulk destructive actions and session monitoring are the counterparts. The Stryker Intune wipe is the example: an administrator account was used to create a new Global Administrator and issue remote wipe commands across tens of thousands of devices, with no second approval in the way.
• Credential theft from the admin's own device: M1026 reduces where privileged credentials appear, but a compromised admin workstation still yields them; M1025, M1043 and privileged access workstations address this.
• Authentication weaknesses: phishing or password spraying of an admin account is M1032 and M1027 territory.
• Vulnerabilities that grant privilege directly: kernel or service exploits (T1068) bypass account boundaries; patching (M1051) applies.

Verifying it works

• Windows: collect Security event 4672 (special privileges assigned to new logon) and group change events 4728, 4732 and 4756; alert when a privileged account logs on to a host outside its plane.
• Cloud: alert on role assignments made outside PIM or your JIT process and on any new Global Administrator or equivalent, as Microsoft recommends for direct assignments.
• Attack path analysis: run graph-based path analysis of Active Directory and cloud tenants periodically and track the number of paths from ordinary users to the control plane.
• Purple team: test Kerberoasting yield (how many crackable service accounts with privileged group membership) and local admin reuse across hosts.

Metrics: number of standing (permanent) assignments to the highest roles; percentage of privileged human accounts that are JIT-eligible only; number of service accounts in privileged groups; privileged logons outside the permitted plane per month; median age of privileged role reviews; agent tool credentials with write or delete scope and no approval gate.

Related D3FEND countermeasures and framework mapping

MITRE D3FEND relates M1026 to D3-DAM Domain Account Monitoring, D3-LAM Local Account Monitoring and D3-SPP Strong Password Policy.

Common failure patterns

• Service accounts in Domain Admins. The single most common finding behind Kerberoasting impact, and directly against ATT&CK's T1484 and T1558.003 guidance.
• Hybrid admin accounts. Synchronised on-premises accounts holding cloud admin roles let an on-premises compromise reach the tenant (T1021.007).
• JIT with permanent exceptions. A few standing Global Administrators left over from the migration defeat the model.
• Destructive actions with a single approver. Bulk wipe, delete or role assignment actions that one identity can complete alone, as at Stryker.
• Broad tokens handed to automation. Account-scoped CI/CD, platform or agent tokens where a scoped one exists, as at PocketOS.
• Reviews that only cover humans. Workload identities and service principals with admin roles are left out of quarterly reviews.

Practitioner checklist

• Inventory all privileged human, service, workload and agent identities, with an owner each.
• Give every administrator a separate admin account per plane, cloud-only for cloud administration.
• Convert standing high-privilege roles to just-in-time with MFA, justification and approval.
• Remove service accounts from Domain Admins and other privileged groups; vault and rotate what remains.
• Deploy unique local administrator passwords and deny network logon for local accounts.
• Require a second approver for bulk destructive actions in device management and cloud consoles.
• Scope agent and automation tokens to one environment and one purpose, with approval for delete and admin actions.
• Alert on privileged assignments outside the JIT process and on privileged logons outside the permitted plane.
• Track the M1026 rows above in your ATT&CK coverage tracker, starting with the three techniques that rely on it alone.

Standards and references

• MITRE ATT&CK: M1026 Privileged Account Management
• Microsoft Learn: Enterprise access model
• Microsoft Learn: Protecting Microsoft 365 from on-premises attacks
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management
• Linux kernel documentation: Yama
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE D3FEND: Domain Account Monitoring

Related NHI Mgmt Group resources: Privileged Access Management Guide · JIT Access Guide · Service Account Security Guide · M1025 Privileged Process Integrity · M1027 Password Policies