M0926: Privileged Account Management
Manage the creation, modification, use, and permissions associated to privileged accounts, including SYSTEM and root.
Analyst context for executives and security teams
Privileged Account Management matters in ICS because highly privileged accounts can determine whether an intruder can move from access to meaningful operational harm. MITRE defines this mitigation as managing the creation, modification, use, and permissions of privileged accounts, including SYSTEM and root. In the supplied relationships, this control helps reduce risk tied to valid account abuse, exploitation of remote services, public-facing application compromise, network sniffing, data collection from repositories, and data destruction.
Executive priority
Treat this as a governance and resilience priority, not only an IT administration task. Leaders should ask whether privileged accounts in industrial environments are known, owned, approved, periodically reviewed, and restricted to business need. The attached IEC 62443 and NIST AC-2 mappings make this a useful control area for compliance evidence, audit readiness, and incident decision-making, especially where privileged access could affect control system availability, sensitive engineering repositories, or recovery from destructive activity.
Technical view
SOC, IR, and identity teams should validate that privileged account inventories, permission changes, and privileged use are visible and reviewable across relevant ICS and supporting environments. Because MITRE provides no detection text and no specific platforms for this mitigation, local architecture must drive implementation and monitoring. Relationship context suggests prioritizing privileged access paths that could enable valid account misuse, remote service abuse, access to information repositories, or destructive actions.
Likely telemetry
- Privileged account inventory and ownership records
- Account creation, modification, disablement, and deletion events
- Privilege assignment and permission change logs
- Authentication and session activity for administrative, SYSTEM, root, service, and shared privileged accounts
- Remote access and remote service authentication records where available
Detection direction
- Confirm that privileged account changes are logged and reviewed, since MITRE does not provide detection guidance for M0926.
- Baseline expected privileged account use and investigate use outside approved maintenance, engineering, or administrative windows.
- Tune alerts around creation of new privileged accounts, privilege escalation, dormant privileged account use, and unexpected SYSTEM/root-level activity.
- Correlate privileged account activity with relationship-relevant behaviors such as valid account use, remote service access, repository access, and destructive file or data operations.
- Account for false positives from legitimate maintenance, vendor support, and emergency operations, especially in ICS environments where operational work may occur outside normal IT patterns.
Mitigation priorities
- Maintain an authoritative inventory of privileged accounts, including SYSTEM, root, service, administrative, and shared accounts where they exist.
- Define ownership, business justification, approval workflow, and review cadence for privileged accounts.
- Limit privileged permissions to required roles and remove unnecessary or stale access.
- Apply stronger review and monitoring to privileged accounts that can reach public-facing applications, remote services, information repositories, or systems where destructive actions would affect operations.
- Integrate privileged account management evidence into incident response procedures so responders can quickly identify, disable, or review high-risk accounts during an event.
Analyst notes and limits
This is an ATT&CK for ICS mitigation object, not a technique. Its value is in reducing the blast radius and persistence value of privileged account compromise across the related techniques. For Glexia-style assessment, the key questions are whether privileged access is inventoried, governed, monitored, and usable as evidence during an incident or audit.
The supplied ATT&CK object does not specify platforms, tactics, or detection guidance. The related technique descriptions are partially truncated in the provided source. Any conclusion about actual exposure, coverage, tooling, or exploitation requires local environment evidence.
Privileged Account Management
Manage the creation, modification, use, and permissions associated to privileged accounts, including SYSTEM and root.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0859 | Valid Accounts | Audit domain and local accounts and their permission levels routinely to look for situations that could allow an adversary to gain system wide access with stolen privileged account credentials. CitationMicrosoft May 2017 CitationMicrosoft August 2018These audits should also identify if default accounts have been enabled, or if new local accounts are created that have not be authorized. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers. CitationMicrosoft February 2019 |
| ICS | T0842 | Network Sniffing | Restrict root or administrator access on user accounts to limit the ability to capture promiscuous traffic on a network through common packet capture tools. CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0866 | Exploitation of Remote Services | Minimize permissions and access for service accounts to limit impact of exploitation. CitationKeith Stouffer May 2015 |
| ICS | T0811 | Data from Information Repositories | Minimize permissions and access for service accounts to limit the information that may be exposed or collected by malicious users or software. CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0819 | Exploit Public-Facing Application | Use least privilege for service accounts. CitationKeith Stouffer May 2015 CitationNational Institute of Standards and Technology April 2013 |
| ICS | T0809 | Data Destruction | Minimize permissions and access for service accounts to limit the information that may be impacted by malicious users or software. CitationNational Institute of Standards and Technology April 2013 |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 21cb4f6d7a80… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M0926Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.