M1018 User Account Management: Account Lifecycle Controls Mapped to ATT&CK Techniques

Most ATT&CK techniques need an account with the right permissions, and M1018 User Account Management is the mitigation that decides which accounts exist and what they can do. In ATT&CK v20, M1018 has 123 active "mitigates" relationships (52 techniques plus their sub-techniques), more than almost any other Enterprise mitigation, spanning every tactic from Initial Access to Impact. This guide reads M1018 as a control a team implements: which techniques it actually blunts, how to prioritise the work, where service accounts, CI/CD identities and AI agents fit, what it does not stop, and how to prove it works. It is written for detection engineers, identity and IAM teams, and security architects mapping coverage. Lifecycle process detail lives in the Joiner-Mover-Leaver Guide and the foundations in IAM and IGA Basics; this page does not repeat them.

Key takeaways

• M1018 is a permissions control, not an authentication control. ATT&CK's usage text for most of the 123 entries says the same thing in different words: limit who can create, modify, run or reach a resource. Strong passwords and MFA belong mostly to M1027 and M1032.
• Privilege Escalation and Persistence dominate the mapping. 35 entries sit under Privilege Escalation and 32 under Persistence, so M1018 matters most after the attacker is already in, by denying the next step.
• Non-human accounts are inside the scope. ATT&CK's own text names CI/CD pipeline permissions (T1677), Kubernetes service account tokens (T1528), third-party provider accounts (T1072, T1199) and dedicated identities for AI agents (T1698, T1699).
• Dormant and leftover access is the highest-value fix. ATT&CK's first mitigation for T1078 Valid Accounts is to audit accounts for activity and remove those no longer needed, which is exactly the gap behind several live incidents.
• Measure it as coverage plus hygiene. Track the share of M1018-mapped techniques you have a configured control for, alongside dormant account counts, standing privilege and review completion.

What M1018 covers in ATT&CK v20

MITRE defines User Account Management as implementing and enforcing policies for the lifecycle of user accounts, including creation, modification and deactivation. The mitigation page lists the practices it expects: least privilege with regular audits of excess permissions, management of dormant and orphaned accounts (the example given is disabling after 30 days of inactivity), account lockout thresholds, MFA for administrative and high-risk accounts, and restricting interactive logins for privileged accounts to secure systems. It names directory services, Group Policy, identity providers and PAM tooling as implementation routes.

Two parts of that description need a practitioner's reading. First, the page's example of password expiry every 90 days is an example, not a requirement; NIST SP 800-63B does not call for periodic password changes without evidence of compromise, so follow your password standard and the M1027 Password Policies page rather than this line. Second, lockout and MFA overlap with M1036 Account Use Policies and M1032 Multi-factor Authentication; in practice M1018 is the lifecycle and entitlement part of the job.

In D3FEND, the M1018 entry is related to three defensive techniques: D3-LFP Local File Permissions, D3-SCF System Call Filtering and D3-SCP System Configuration Permissions. That is a narrow, host-focused mapping; the cloud and identity provider half of M1018 has no direct D3FEND counterpart in that entry.

Techniques M1018 mitigates, by tactic

The 123 relationships fall across all tactics (a technique can sit under several). Counts below are tactic memberships from the v20 dataset, so they add up to more than 123.

The 20 entries to prioritise

The table below is the NHI Mgmt Group priority view: techniques where the M1018 control is the main preventive lever, not a minor one, with ATT&CK's own guidance paraphrased.

Implementing M1018 well

Treat M1018 as four control families, each tied to technique groups, so work can be planned and measured.

1. Inventory every account, human and non-human: directory users, local accounts, cloud IAM users and roles, service principals, Kubernetes service accounts, CI/CD identities, API keys and AI agent identities, each with an accountable owner. CIS Controls v8.1 Safeguards 5.1 (inventory of accounts) and 5.5 (inventory of service accounts) set this as the starting point. Without it, T1078 and T1036.010 cannot be addressed because you cannot tell a legitimate account from an unexpected one. See the Service Account Inventory Template.
2. Remove what is not needed: disable dormant accounts (CIS Safeguard 5.3 Disable Dormant Accounts; NIST SP 800-53 AC-2(3) Disable Accounts) and revoke access on departure across every system, including package registries, source control and SaaS. The Orphaned and Dormant Accounts guide covers detection thresholds.
3. Constrain who can change identity and policy: this is the high-yield block for Persistence and Privilege Escalation. Inventory every principal that can create users, add keys, grant roles, modify conditional access, create federation trusts or assume privileged roles, and cut it to a named, reviewed group. In Entra ID, restrict user consent to apps from verified publishers for low-impact permissions (the microsoft-user-default-low policy, which Microsoft recommends) to cover the T1566.002 consent route; see the Consent Phishing and Illicit OAuth Grants Guide.
4. Scope workload and automation identities: pipelines, deployment tools, containers, serverless functions and agents get their own identities with task-scoped permissions, separate identities per environment, and no standing access to backups or logging configuration. See the CI/CD Pipeline Identity Security Guide and the Kubernetes Service Account Token Guide.

Rollout sequence

1. Week 1 to 4, discover: export accounts, last sign-in and group or role membership from each directory and cloud tenant; flag accounts with no owner and no activity in your threshold (CIS uses 45 days for Safeguard 5.3).
2. Pilot: disable, do not delete, a first cohort of dormant human accounts, and hold dormant service accounts in a monitored "disable candidate" state for one full business cycle (month-end and quarter-end jobs are the common surprise).
3. Restrict administrative change rights: move identity, policy and logging administration to dedicated admin accounts (CIS Safeguard 5.4) with just-in-time elevation through your Privileged Access Management Guide process.
4. Scope NHIs: replace broad tokens with task-scoped ones, one environment at a time, in report-only or audit mode where the platform supports it.
5. Roll back safely: re-enable a disabled account (never recreate it, which breaks audit trails), and keep the previous role definition versioned so a scoping change can be reverted in one step.
6. Operationalise: schedule access reviews, with privileged and non-human entitlements reviewed more often. See the Access Reviews Guide.

Small and large organisations

A small organisation with one identity provider and one cloud can get most of the value from three moves: a single identity source, dormant account disabling, and a short named list of people who can change identity and security settings. A large enterprise with several directories, tenants and acquired estates needs IGA tooling for joiner, mover and leaver automation, a central NHI inventory, and per-platform ownership for the "who can change identity" lists, because no single team can see them all. In both cases the cheapest early win is the same: find accounts with no recent activity and no owner.

Where non-human identities fit

ATT&CK v20 has moved M1018 well beyond human users. The usage text for T1677 Poisoned Pipeline Execution asks for minimal pipeline permissions; T1528 asks to stop automounting Kubernetes service account tokens; T1072 asks that third-party provider accounts be traceable and reviewed; T1685.007 Impair Autonomous Defenses asks that AI-assisted analysis services run under dedicated identities with limited permissions; and T1698 asks that AI agents have dedicated identities scoped to the approved workflow, so retrieved content cannot change their authorisation context.

The PocketOS database deletion shows why this matters. An AI coding agent working in staging found an account-scoped platform token stored in the codebase, created for domain management, and used it to delete the production database and its volume-level backups in one call. A task-scoped token, separated environments and backups outside the reach of that credential are all M1018 controls. For agents specifically, see the Agent Identity and Access Guide; for service accounts, the Service Account Security Guide.

What M1018 does not stop

• Use of a legitimate, correctly scoped account: if a stolen credential belongs to an active account that needs its access, M1018 has nothing to remove. MFA (M1032), session controls and detection carry that risk.
• Exploits that skip the permission model: T1068 Exploitation for Privilege Escalation and kernel or hypervisor flaws reach privileges no account was granted. Patching (M1051) and exploit protection (M1050) cover these.
• Attackers who already hold administrator rights: ATT&CK says plainly for T1134 Access Token Manipulation that the adversary must already have administrator access on the local system; M1018 reduces how many accounts have that, but does not constrain the administrator.
• Token and session theft: stolen session cookies and refresh tokens bypass account status until they expire or are revoked; covered by session lifetime and revocation controls.
• Misuse inside an allowed scope: an insider or compromised agent doing harmful things it is permitted to do needs monitoring and approval gates, not account management.

Detection and measurement

M1018 is preventive, so pair it with detections that show when it has drifted or been bypassed.

Metrics that show the control is working:

• Dormant account count: enabled accounts with no activity beyond the threshold, split human and non-human, trending to near zero.
• Ownerless NHI percentage: service accounts, keys and agents with no named owner.
• Identity change rights: number of principals able to create users, add keys, assign roles or change conditional access, per tenant.
• Leaver revocation time: median hours from termination to access removed across all systems, not just the directory.
• Review completion: percentage of privileged and non-human entitlements certified on schedule.
• M1018 technique coverage: share of the 123 mapped entries, or of your prioritised 20, with a configured control and an owner. See the MITRE ATT&CK Coverage Mapping Guide.

Common failure patterns

• Disabling the directory account and forgetting everything else. In the Ledger Connect Kit compromise, a former employee's internal access had been removed, but their npm publishing access had not; attackers phished that person and pushed malicious package versions.
• Leaving unused remote access accounts enabled. The Colonial Pipeline attack began with a legacy VPN account no longer in use but never disabled, whose password appeared in leaked credentials and which had no MFA.
• Account-scoped tokens for narrow tasks. One token that can reach every environment turns a staging mistake or a leaked secret into a production incident.
• Treating M1018 as human-only. Reviews that cover employees but skip service principals, deploy keys and agent identities leave the T1677, T1528 and T1698 entries unmitigated.
• Too many people can change identity policy. Broad helpdesk or application administrator roles that can reset admin credentials or edit conditional access undo the rest of the work.
• Deleting instead of disabling. Deleting accounts on day one removes audit history and makes rollback harder; disable first, delete after a retention period.

Framework mapping

Related mitigations: M1026 Privileged Account Management (admin accounts specifically), M1032 Multi-factor Authentication, M1036 Account Use Policies, M1027 Password Policies and M1015 Active Directory Configuration.

Practitioner checklist

• Build one inventory of human and non-human accounts with owners, last activity and privilege level.
• Disable accounts inactive beyond a set threshold, and hold service accounts in a monitored disable-candidate state first.
• Revoke leaver access across registries, source control, SaaS and cloud, not only the directory.
• List every principal that can create users, add keys, grant roles or change conditional access, and cut it to a reviewed group.
• Give pipelines, deployment tools, containers and AI agents their own task-scoped identities per environment.
• Set automountServiceAccountToken: false for pods that do not call the Kubernetes API.
• Keep backup deletion and logging configuration rights away from day-to-day and workload identities.
• Restrict user consent to verified publishers and low-impact permissions where your IdP supports it.
• Alert on dormant account sign-ins, new credentials and privileged group changes.
• Report dormant counts, ownerless NHIs and M1018 technique coverage every quarter.

Standards and references

• MITRE ATT&CK: M1018 User Account Management
• MITRE ATT&CK: T1078 Valid Accounts
• MITRE D3FEND: System Configuration Permissions
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• CIS: Control 5 Account Management
• Microsoft Learn: Configure how users consent to applications
• MITRE ATT&CK: T1528 Steal Application Access Token

Related NHI Mgmt Group resources: Joiner-Mover-Leaver Guide · Orphaned and Dormant Accounts · Least Privilege Techniques Guide · Service Account Security Guide · MITRE ATT&CK T1078 Valid Accounts Guide