M0954: Software Configuration
Implement configuration changes to software (other than the operating system) to mitigate security risks associated with how the software operates.
Analyst context for executives and security teams
Software Configuration is an ICS ATT&CK mitigation focused on reducing risk by changing how non-operating-system software is configured. For leaders, its value is governance and resilience: many security outcomes depend less on buying new tools and more on proving that critical applications, engineering software, services, and supporting platforms are configured to operate safely and with minimal unnecessary capability.
Executive priority
Prioritize this as a control assurance issue, not just an IT hygiene task. The object maps to IEC 62443 SR/CR 7.7 and NIST SP 800-53 CM-7, so it can support compliance evidence around least functionality and secure configuration. Executives should ask which critical ICS-related software has approved configuration baselines, who owns deviations, and how configuration changes are reviewed before they affect operational continuity.
Technical view
Because ATT&CK provides no platform, tactic, detection text, or relationship context for M0954, SOC and IR teams should treat it as a preventive control area rather than a behavior-specific detection analytic. Validate that security-relevant configuration settings for non-OS software are documented, version-controlled where possible, reviewed after changes, and tied to change management. In ICS environments, confirm that configuration hardening does not disrupt safety, availability, or vendor-supported operation.
Likely telemetry
- Software configuration baselines and approved build documentation
- Application and service configuration files or exported settings
- Change management records and approval history
- Asset inventory identifying critical non-OS software
- Configuration assessment or compliance scan results where available
Detection direction
- Do not assume ATT&CK supplies a detection analytic for this mitigation; detection must come from local configuration monitoring, change records, and administrative audit evidence.
- Validate whether teams can identify unauthorized, unexpected, or undocumented changes to security-relevant software settings.
- Tune review processes to distinguish approved operational changes from risky drift, especially where ICS uptime or vendor constraints limit automated enforcement.
- Use compliance mappings to IEC 62443-3-3 SR 7.7, IEC 62443-4-2 CR 7.7, and NIST SP 800-53 CM-7 as evidence anchors, but verify that the evidence reflects actual deployed configurations.
Mitigation priorities
- Define approved secure configuration baselines for critical non-OS software.
- Remove or disable unnecessary software features, services, or functions when operationally safe and vendor-supported.
- Integrate configuration changes into formal change control with documented risk acceptance for deviations.
- Periodically compare deployed settings against approved baselines and investigate drift.
- Coordinate security, operations, engineering, and vendor stakeholders before enforcing changes in ICS environments.
Analyst notes and limits
This object is a mitigation, not an adversary technique. Its decision value is in control validation: whether the organization can show that important software is configured intentionally, consistently, and with unnecessary functionality reduced. The supplied relationship context is empty, so no specific ATT&CK techniques or platforms should be inferred.
ATT&CK provides only a short mitigation description, compliance-related labels, and no official detection guidance, platforms, tactics, or relationships for this object. Local asset criticality, software types, vendor requirements, and operational constraints are required to turn this into a specific control plan.
Software Configuration
Implement configuration changes to software (other than the operating system) to mitigate security risks associated with how the software operates.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 8b714c4bb822… |
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 M0954Open 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.