AC-7(2): Purge or Wipe Mobile Device

AC-7(2) requires you to automatically purge or wipe information from mobile devices after a defined number of consecutive failed unlock (logon) attempts, using documented wipe techniques and thresholds. To operationalize it, you must standardize device settings through MDM, define exceptions, test the wipe trigger, and retain proof that the configuration is deployed and effective. ¹

Key takeaways:

• Set a clear failed-attempt threshold and enforce it via MDM across in-scope mobile devices. ¹
• Define what “purge” vs “wipe” means for your data and devices, then document the technique and trigger. ¹
• Keep evidence that settings are deployed, monitored, and tested, not just written in policy. ¹

AC-7(2): Purge or Wipe Mobile Device is a specific enhancement under NIST SP 800-53’s Access Control family that focuses on what happens after repeated failed device logon attempts on mobile endpoints. The control is designed to reduce the risk that a lost, stolen, or targeted device can be brute-forced offline until the attacker gains access to sensitive data stored locally.

For most programs, the operational challenge is not writing the policy. It’s aligning multiple moving parts: which devices are in scope (corporate-liable, BYOD, rugged devices), what data is present (email, cached documents, offline app data), what wipe action is acceptable (selective wipe vs full device wipe), and how to prove the control actually works across a fleet.

This page gives you requirement-level implementation guidance you can put into a control card/runbook: scoping, configuration, exception handling, monitoring, validation testing, and the evidence bundle auditors typically expect. The goal is fast, defensible implementation that holds up in a federal system authorization, contractor flowdown, or customer diligence review. ²

Regulatory text

Requirement (verbatim excerpt): “Purge or wipe information from [mobile devices] based on [purging or wiping requirements and techniques] after [number] consecutive, unsuccessful device logon attempts.” ¹

What the operator must do

You must:

1. Identify the mobile devices in scope (the bracketed “[mobile devices]” is your scoping decision).
2. Define the wipe approach and technique (the bracketed “[purging or wiping requirements and techniques]” is your technical standard: full wipe, selective wipe, cryptographic erase, etc.).
3. Set the failed logon threshold (the bracketed “[number]” is your parameter) and ensure the device enforces it automatically.
4. Demonstrate the control operates through configuration evidence and validation (test results, monitoring, and exceptions). ¹

Plain-English interpretation

After too many failed unlock attempts, the device must automatically remove sensitive data so an attacker cannot keep guessing until they get in. Your job is to pick the threshold, pick the wipe method, push the setting to devices consistently, and prove it is enabled and effective.

This control is strongest when combined with encryption, strong authentication, and centralized mobile device management (MDM). AC-7(2) is the “last line” if the device falls into hostile hands and online defenses (conditional access, MFA) do not apply because the attacker is working locally.

Who it applies to

Entity scope

AC-7(2) is commonly applicable in:

• Federal information systems implementing NIST SP 800-53 controls.
• Contractor systems handling federal data, including environments where NIST SP 800-53 is contractually flowed down. ¹

Operational context (what “in scope” usually means)

Treat a device as in scope when it:

• Stores, caches, or can access controlled data (federal data, CUI, regulated data, sensitive internal data).
• Is allowed to authenticate to your environment (email, VPN, enterprise apps) and can retain data offline.
• Is managed (or should be managed) via an MDM/UEM or equivalent administrative control plane.

Include:

• Corporate-issued iOS/iPadOS and Android devices.
• Shared-use/rugged devices if they access or store sensitive data.
• BYOD devices if they access sensitive data and you allow local caching inside a managed container.

Exclude only with documented rationale and compensating controls (for example, truly kiosk-like devices with no sensitive local storage and locked-down OS profiles).

What you actually need to do (step-by-step)

Step 1: Write the control card (make it executable)

Create a single-page control card/runbook that states:

• Objective: Prevent offline brute-force access by wiping/purging after consecutive failed unlock attempts.
• Owner: Endpoint Security or IT, with Compliance as oversight.
• In-scope assets: Device types, OS versions, ownership model (COPE/BYOD), and business units.
• Trigger: Consecutive failed device logon attempts.
• Action: Purge or wipe method, plus who is notified.
• Exceptions: Approval path, time-bounded exceptions, and compensating controls.

This is the artifact auditors ask for when they want “how it runs,” not “what the policy says.”

Step 2: Decide “purge” vs “wipe” for your risk and data model

Make a clear decision that maps to your environment:

| Option | What it means in practice | Where it fits | Audit risk if unclear | |---|---|---| | Full device wipe | Resets device to factory state; removes all local data | High-risk data, corporate-owned devices | Low ambiguity, but disruptive | | Selective wipe / enterprise wipe | Removes managed profiles/apps/data; leaves personal data | BYOD, privacy-sensitive contexts | Must prove sensitive data is only in the managed container | | Cryptographic erase | Destroys encryption keys so data is unreadable | Encrypted storage with strong key management | Must prove encryption + key destruction are effective |

Pick one as your default standard per device category, and document the technique. ¹

Step 3: Set the failed logon threshold (the “[number]”)

Define the threshold based on your risk tolerance, user population, and device types. The requirement does not give the number; you must set it and make it consistent.

Implementation expectation: the threshold must be enforced technically (MDM configuration / OS policy), not left to user choice, and exceptions must be controlled.

Step 4: Implement via MDM/UEM configuration baselines

Operationalize through configuration baselines:

• Create a “Mobile Device Passcode/Unlock Baseline” that includes:
  • Maximum failed passcode attempts before wipe/purge.
  • Passcode complexity and timeout settings (supporting controls; keep scope tight here).
• Assign baselines by device group (corporate vs BYOD vs shared).
• Block access for noncompliant devices (conditional access or equivalent) so devices without the setting cannot connect.

Your evidence should show that the policy is deployed to the targeted population and that noncompliant devices are identified and remediated.

Step 5: Define notification and response handling

Decide what happens when a wipe is triggered:

• Who gets alerted (SOC, IT, user’s manager)?
• How you validate whether it was user error, theft, or attack?
• What user re-enrollment steps exist, and how you preserve business continuity without weakening the control.

Keep the runbook short. The goal is predictable execution.

Step 6: Validate the control with a controlled test

Run a documented validation:

• Use a test device in each major platform group.
• Confirm that after the configured number of failed unlock attempts, the device purges/wipes as designed.
• Capture screenshots, MDM event logs, and a short test record (device ID, OS, date, tester, outcome, ticket/reference).

Testing is often the difference between “configured” and “working.”

Step 7: Ongoing monitoring and “control health”

Operate the control like a living requirement:

• Monitor MDM compliance reports for drift (devices without the baseline, failed policy application, jailbroken/rooted flags if available).
• Track exceptions with expiry dates and re-approval rules.
• Review wipe events periodically to confirm they are expected and investigated when suspicious.

If you use Daydream, treat AC-7(2) as a requirement with a mapped evidence bundle: baseline configuration export, device compliance report, test record, and exception register. Daydream is most useful when you need to answer diligence quickly with consistent artifacts and a clear owner/cadence.

Required evidence and artifacts to retain

Retain evidence that proves both design and operation:

Design-time artifacts

• Control card/runbook (owner, scope, trigger, action, exceptions).
• Mobile device security standard (purge/wipe technique definitions).
• MDM/UEM baseline configuration (export, screenshots, or policy JSON).
• Exception procedure and compensating control templates.

Operating evidence

• Current device inventory and in-scope grouping (export from MDM/UEM).
• Compliance report showing baseline applied to in-scope devices.
• Logs/events of wipe triggers (with ticket references and triage notes).
• Validation test record(s) demonstrating wipe/purge works.
• Exception register with approvals, rationale, expiry, and closure evidence.

Retention period is program-dependent; keep it consistent with your system’s audit and authorization needs.

Common exam/audit questions and hangups

Expect these questions in assessments against NIST SP 800-53:

1. “What is your failed logon threshold and where is it enforced?”
   Show the MDM policy and a compliance report, not a policy PDF.

2. “Define purge vs wipe for your implementation.”
   If you claim “purge,” auditors will ask what exactly is purged (managed app data, encryption keys, full reset) and how you know.

3. “Which devices are in scope, including BYOD?”
   Be ready to explain scoping logic and how you prevent unmanaged devices from accessing sensitive data.

4. “How do you know the setting works?”
   Provide test evidence and/or event logs.

5. “How do you handle exceptions?”
   Time-bound, approved, documented compensating controls. No informal exceptions.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Relying on user-configured settings.
  Fix: enforce through MDM/UEM and block access for noncompliance.

• Mistake: Claiming “selective wipe” while allowing sensitive data outside the container.
  Fix: enforce managed app/container storage rules and restrict copy/paste and local saves where needed; document the boundary clearly.

• Mistake: No evidence of operation.
  Fix: keep a minimum evidence bundle and run periodic control health checks (inventory, compliance, exceptions, wipe events). ¹

• Mistake: Exceptions that never expire.
  Fix: require expiry dates, re-approval, and automated reminders/tickets.

• Mistake: Not testing after OS/MDM changes.
  Fix: re-validate after major OS upgrades, MDM policy refactors, or device fleet changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific control enhancement. Treat AC-7(2) primarily as an assurance and harm-reduction control: when mobile devices are lost or attacked, a working wipe-on-failure setting can materially reduce the chance of offline access to cached data. ¹

Practical 30/60/90-day execution plan

Use phases rather than date promises; the right pace depends on fleet size, MDM maturity, and BYOD posture.

First 30 days (Immediate)

• Confirm device scope and ownership models (COPE/BYOD/shared).
• Draft the control card: threshold, purge/wipe technique, owner, exceptions.
• Identify where sensitive data is stored locally (email, files, line-of-business apps).
• Pick the default wipe action per device category and document it.

By 60 days (Near-term)

• Build and deploy the MDM baseline to a pilot group per platform.
• Configure conditional access or enrollment controls to prevent unmanaged devices from accessing sensitive resources.
• Stand up the exception workflow and register.
• Execute validation tests and document results.

By 90 days (Operationalize and stabilize)

• Roll out to all in-scope devices with staged change management.
• Implement monitoring dashboards and a simple recurring control health review (compliance drift, exceptions, wipe events).
• Run a tabletop for wipe events (lost device vs user error vs suspected attack) and tighten the runbook based on lessons learned.
• Store the evidence bundle in a consistent location and map it to AC-7(2) for audit readiness (Daydream can hold the requirement, owner, cadence, and artifacts in one place). ¹

Frequently Asked Questions

Does AC-7(2) require a full factory reset, or is selective wipe acceptable?

The text allows “purge or wipe” based on your defined techniques, so selective wipe can be acceptable if it reliably removes the sensitive information your users can access on the device. Document the technique and prove the data boundary (managed container vs personal space). ¹

What counts as a “device logon attempt” for this control?

Treat it as the device unlock event (PIN/password/biometric fallback) because that is the gate to locally stored data. Document your interpretation in the control card and map it to the enforced OS/MDM setting. ¹

How do we handle BYOD without wiping personal photos and apps?

Use a managed container/work profile model and configure selective wipe for the managed profile after failed attempts, if your platform supports it. Your evidence must show sensitive data stays in the managed space so selective wipe truly purges the regulated content. ¹

What evidence is strongest for auditors: policy statements or MDM screenshots?

Auditors usually want both, but operating evidence carries the control: exported MDM configuration, compliance reports, and test records that show the wipe trigger works. Keep them tied together with an owner and a repeatable check cadence. ¹

If we already encrypt mobile devices, do we still need wipe-on-failure?

Encryption helps, but AC-7(2) specifically addresses repeated failed logon attempts and requires a purge/wipe action after a defined threshold. Keep encryption as a supporting control, and implement the wipe trigger as the explicit AC-7(2) mechanism. ¹

How should we document and manage exceptions?

Require a written rationale, approver, compensating controls, and an expiry date, and track it in an exception register tied to the device/user identity. Auditors will focus on whether exceptions are controlled and time-bounded. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON