M1011: User Guidance
Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.
Security context for executives and security teams
User Guidance is a mobile ATT&CK mitigation centered on teaching users which risky prompts, permissions, and behaviors to avoid or configure safely. Its business value is highest where mobile devices handle credentials, authentication codes, location data, calls, audio, notifications, or sensitive applications. The key decision is not whether training exists, but whether it is specific enough to reduce consent-based abuse such as approving third-party keyboards, accessibility access, microphone/location permissions, device administrator rights, SMS/call access, or suspicious mobile management requests.
Executive priority
Treat this as a resilience and risk-reduction control for mobile workforces, especially where mobile devices are used for identity verification, executive communications, field operations, or regulated data access. User guidance should be backed by measurable mobile governance evidence: what users are told, which device permissions are monitored, which risky grants are restricted, and how exceptions are reviewed. By itself, guidance is not a substitute for MDM/EMM controls, mobile telemetry, or incident response playbooks.
Technical view
ATT&CK provides no official detection text for M1011, so SOC and mobile security teams should validate this mitigation through the techniques it is mapped to. The relationship context points to Android and iOS risks involving input capture, keylogging, software/security software discovery, audio capture, location tracking, SIM swap, Android accessibility abuse, removable media/USB exposure, screen capture, notification access, SMS/call control, device administrator permissions, foreground persistence, execution guardrails/geofencing, hidden app icons, and defense impairment. Detection engineers should confirm whether mobile telemetry can show risky permission grants, changes to device administration or accessibility settings, third-party keyboard authorization, default SMS handler changes, location/microphone access, notification access, app inventory changes, and mobile management or cloud device-location console activity.
Likely telemetry
- MDM/EMM device inventory and compliance state
- Mobile application inventory and app install/uninstall records
- Android accessibility service enablement events
- Android device administrator permission grants and removals
- Mobile OS permission state for microphone, location, SMS, calls, notifications, screen capture, and related sensitive access
Detection direction
- Do not measure this mitigation only by completion of awareness training; validate whether device state and mobile telemetry show reduced risky permissions and configurations.
- Prioritize detection logic around user-consent events that enable sensitive access, including accessibility, device administrator, notification access, microphone, location, SMS, call, screen capture, and third-party keyboard permissions.
- Tune for context: some permissions are legitimate for approved business apps, accessibility tools, MDM agents, security products, and communications apps, so allowlisting and ownership metadata are important to reduce false positives.
- Look for combinations of risky grants rather than single events when possible, such as accessibility plus SMS access, device administrator plus uninstall resistance, or location access plus foreground persistence.
- Confirm whether Android-only relationships are covered separately from Android/iOS relationships; ATT&CK maps several related techniques to Android only.
Mitigation priorities
- Create mobile-specific user guidance that names the risky decisions users actually see: permission prompts, accessibility requests, third-party keyboard approvals, device administrator prompts, notification access, SMS/call access, location sharing, microphone access, and remote device-management requests.
- Pair guidance with enforceable mobile policy where possible, including MDM/EMM baselines, approved app sources, permission restrictions, app inventory review, and compliance reporting.
- Address identity and help desk processes tied to SIM swap risk, including user verification expectations and escalation paths for unexpected loss of service or account recovery prompts.
- Give users clear reporting channels for suspicious prompts, hidden or hard-to-remove apps, unexpected device management messages, unusual battery/sensor behavior, or changes to SMS/call behavior.
- For higher-risk users or regulated workflows, validate that guidance is evidenced through audits: training content, acknowledgement, device compliance snapshots, exception records, and incident response lessons learned.
Additional notes and limits
This is a course-of-action object, not a technique. The official description is broad and the detection field is not provided, so the strongest analytic value comes from the listed mitigation relationships. The mapped techniques show that user guidance is most relevant when adversary behavior depends on user consent, permission grants, social engineering, or risky mobile configuration choices. Local mobile platform mix, MDM visibility, approved app catalog, and identity support processes will determine how actionable this mitigation is.
ATT&CK does not specify platforms or tactics for M1011 itself, and provides no official detection guidance. Platform references come from the related techniques only. This summary does not establish active exploitation, actor attribution, customer exposure, or guaranteed detection coverage. Organizations need local device telemetry and policy evidence to determine actual control effectiveness.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
User Guidance
Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.
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.
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.
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.