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

AC-7(2) requires you to configure managed mobile devices to automatically purge or wipe specified information after a defined number of consecutive failed device logon attempts, using organization-defined criteria for what gets purged and how. To operationalize it fast, set the wipe/purge threshold in MDM/UEM, define the wipe scope, test it, and retain configuration and test evidence. ¹

Key takeaways:

• AC-7(2) is a device-level control: it triggers after consecutive failed device logons, not app logins. ¹
• You must define three parameters: what information is purged/wiped, the basis/criteria used, and the failed-attempt threshold. ¹
• Audit success depends on MDM configuration proof, testing results, and an exception process for devices that cannot support the feature.

The ac-7(2): purge or wipe mobile device requirement is one of those controls that looks simple until an assessor asks, “Which devices? What is wiped? Exactly when does the wipe occur? Show me it works.” AC-7(2) sits under the NIST SP 800-53 Access Control family and is focused on limiting exposure from brute-force attempts and unauthorized access on mobile devices by forcing a purge/wipe action after repeated failed device logons. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to readiness is to treat AC-7(2) as a parameterized configuration requirement with measurable outcomes: documented thresholds, enforced settings via MDM/UEM, and repeatable evidence. The control’s language includes placeholders for organization-defined parameters, which means you must make explicit decisions and document them. ¹

This page gives you requirement-level implementation guidance you can hand to endpoint engineering and security operations, plus the artifacts you need to retain so you can pass an assessment without scrambling.

Regulatory text

NIST control enhancement excerpt (AC-7(2)): “Purge or wipe information from [organization-defined mobile devices] based on [organization-defined criteria] after [organization-defined number] consecutive, unsuccessful device logon attempts.” ¹

Operator interpretation of the text

• You must identify the in-scope mobile devices.
• You must define what “purge or wipe information” means for your environment (for example: wipe the whole device, wipe enterprise data only, purge keys, remove managed profiles).
• You must set the criteria/basis for applying the purge/wipe (commonly: device ownership model, data sensitivity, user role, or system boundary requirements).
• You must configure the device (usually via MDM/UEM) so the purge/wipe happens after a defined number of consecutive failed device logon attempts, and you must be able to prove it. ¹

Plain-English requirement (what you’re on the hook for)

After someone fails the device unlock too many times in a row, the device must automatically destroy or remove the protected information you specify, according to rules you define and document.

Where AC-7(2) fits in NIST SP 800-53

AC-7 is about unsuccessful logon attempts; the (2) enhancement makes the consequence explicit for mobile devices: purge or wipe rather than only lockouts or alerts. ²

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where 800-53 is a contractual or program requirement. ¹

Operational context (what “mobile device” typically means in practice)

Treat as in-scope any endpoint that:

• Leaves controlled physical spaces regularly, and
• Stores or can access federal or otherwise protected organizational data, and
• Uses a device logon mechanism (PIN, passcode, biometric with fallback PIN, etc.).

Common in-scope categories:

• Corporate-owned smartphones/tablets enrolled in MDM/UEM
• Ruggedized field devices
• BYOD devices with an enterprise/work profile (if your system boundary includes managed corporate data on BYOD)

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

Step 1: Define the three required parameters (document first)

AC-7(2) forces three “organization-defined” decisions. Write them down in a control implementation statement or standard. ¹

Use this table as your decision record:

Parameter you must define	Practical options	Decision output (what auditors want to see)
In-scope mobile devices	All managed mobile devices; only devices with access to certain apps/data; only COPE/COBO	Inventory scope statement tied to MDM enrollment groups
Basis/criteria for purge/wipe	Data classification; ownership model; user role; system boundary	A short rule set: “If device is in group X, enforce action Y”
Failed device logon threshold	A fixed number of failed unlocks	The exact threshold value and where it is configured

Step 2: Choose “purge” vs “wipe” outcomes per device class

You need a defensible mapping between risk and wipe scope.

Practical mapping (example you can adapt):

• Corporate-owned / fully managed: full device wipe after threshold.
• BYOD with managed container/work profile: enterprise wipe (remove work profile/managed apps and keys) after threshold.
• Specialized devices: if full wipe breaks safety/availability needs, document an exception and implement the strongest feasible purge (for example, remove managed keys/data, require re-enrollment, and block access until remediated).

Keep the mapping consistent with your system boundary and data protection objectives. ³

Step 3: Implement enforcement in MDM/UEM (the control is config-driven)

Your endpoint team should configure, at minimum:

• Passcode/PIN policy (complexity, reuse, grace periods as applicable)
• Failed passcode attempt limit
• Wipe/purge action tied to the failed attempt limit
• Controls to prevent users from disabling management controls (where supported)

Operational rule: enforce via configuration profiles to device groups, not by user self-attestation.

Step 4: Confirm the control triggers on device logon attempts

Assessors often catch teams who implemented app-level lockouts and assumed it covered AC-7(2). This control explicitly references device logon attempts. Validate your MDM setting applies to device unlock attempts and produces the wipe/purge action. ¹

Step 5: Test it in a non-production device group and capture results

Run a controlled test:

• Enroll test devices that represent each device class (COBO/COPE/BYOD)
• Apply the policy
• Perform consecutive failed unlock attempts until the threshold is reached
• Verify the expected outcome occurred (full wipe or enterprise wipe/purge)
• Verify post-wipe access is blocked until re-enrollment and compliance checks pass

Step 6: Add an exception process (because some devices will not comply cleanly)

You need a documented path for:

• Devices that cannot support the configured threshold/wipe action
• Devices with operational constraints (field/OT-like use cases)
• Temporary exceptions (executive travel devices, short-term pilots)

Minimum exception fields:

• Device type / OS / owner
• Business justification
• Compensating controls
• Approval
• Review/expiration trigger
• Technical validation that compensating controls are active

Step 7: Operational monitoring and drift control

To keep the control “always on”:

• Monitor compliance status in MDM (policy applied, device compliant/non-compliant)
• Alert on devices not checking in, unenrolled devices, or policy removal attempts
• Review policy assignments after org changes (new groups, new apps, mergers)

If you use Daydream for control operations, map AC-7(2) to a single control owner, a single implementation procedure, and a recurring evidence checklist so you can produce consistent assessor-ready artifacts without rebuilding the story each audit cycle. ¹

Required evidence and artifacts to retain

Keep evidence tied to the three parameters and the “works as configured” proof.

Design evidence (static)

• AC-7(2) control implementation statement with:
  • In-scope mobile device definition
  • Criteria for purge/wipe selection
  • Failed-attempt threshold
• Mobile device security standard (or endpoint baseline) that includes wipe/purge behavior
• Exception procedure and approval workflow

Implementation evidence (configuration)

• MDM/UEM policy screenshots or exported configuration profiles showing:
  • Failed logon attempt limit
  • Wipe/purge setting
  • Target device groups
• Device group membership rules and enrollment requirements

Operating effectiveness evidence (dynamic)

• Test plan and test results (date, tester, device identifiers, outcome)
• Audit logs or MDM events showing a wipe/purge occurred after failed attempts (redact identifiers as needed)
• Periodic compliance reports from MDM showing policy coverage and non-compliance handling

Common exam/audit questions and hangups

Assessors tend to focus on clarity and proof:

1. “Define your organization-defined parameters.” If you cannot point to a written threshold, criteria, and scope, you will lose time in the exam. ¹
2. “Show me the setting in MDM and the targeted population.” Expect requests for configuration exports and assignment scope.
3. “Prove it triggers after consecutive device logon failures.” Testing evidence is the cleanest response. ¹
4. “What about BYOD?” You must show how enterprise data is purged/wiped (work profile removal, managed app data removal) or document why BYOD is out of scope for the system boundary.
5. “How do you handle devices that can’t comply?” You need exceptions with compensating controls, not informal verbal approvals.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Implementing only account lockout, not wipe/purge. AC-7(2) specifically requires purge or wipe after failed attempts. Configure the destructive action. ¹
• Mistake: Applying settings to “most devices” but missing executive/BYOD/test groups. Fix with enrollment gating and automated group assignment rules.
• Mistake: No written criteria for what gets wiped. Write a short decision matrix that maps device class to wipe scope, then align MDM groups to that matrix.
• Mistake: No test evidence. Add a repeatable test procedure and run it when OS versions or MDM platforms change.
• Mistake: Treating “remote wipe” as equivalent to “wipe after failed attempts.” AC-7(2) is about an automatic response after consecutive failed device logons, not a manual remote action. ¹

Enforcement context and risk implications

No public enforcement case references were provided for this requirement in the source catalog, so treat enforcement expectations as assessment-driven rather than case-law-driven. Your practical risk is straightforward: if a device is stolen or an attacker brute-forces the unlock screen, AC-7(2) reduces the chance that sensitive data remains recoverable on the device after repeated guesses. ³

Practical 30/60/90-day execution plan

Use these phases as an operating plan; adjust sequencing to your change-management cadence.

First 30 days (establish decisions + baseline enforcement)

• Name the control owner (Endpoint/IT with Security oversight) and document the three organization-defined parameters for AC-7(2). ¹
• Confirm your authoritative device inventory and identify all enrollment paths (corporate, BYOD, contractors).
• Configure the wipe/purge policy in MDM/UEM for a pilot group that represents each device class.
• Draft exception workflow and identify likely exception populations.

Days 31–60 (expand coverage + prove it works)

• Roll out policies to production device groups based on your criteria matrix.
• Execute and document wipe/purge testing per device class and OS family.
• Implement compliance monitoring dashboards and an escalation runbook for non-compliant devices.
• Train helpdesk on user-impact flows (post-wipe re-enrollment, identity verification).

Days 61–90 (stabilize operations + assessment readiness)

• Run a targeted coverage review: devices enrolled vs. devices in scope, and documented exceptions vs. actual deviations.
• Add drift checks: policy tampering alerts, unenrollment detection, and periodic evidence pulls.
• Package evidence for assessors: decision record, config exports, test results, and exception register.
• If you track controls in Daydream, set a recurring evidence task schedule so AC-7(2) stays audit-ready without manual chasing. ¹

Frequently Asked Questions

Does AC-7(2) apply to application login failures (like a mobile banking app)?

No. The text specifies “device logon attempts,” which assessors interpret as the device unlock/authentication mechanism. ¹

Can “purge” mean removing only corporate data on a BYOD phone?

Yes, if your criteria define that BYOD devices get an enterprise wipe/purge (work profile and managed data removed) rather than a full device wipe. Document the criteria and show the MDM setting enforces it. ¹

What counts as “consecutive, unsuccessful” attempts?

Treat it literally: repeated failed unlock attempts without a successful unlock in between. Your evidence should show the configured threshold and a test that reaches it. ¹

If the OS already wipes after too many failed attempts, do we still need MDM settings?

You still need documented parameters, proof that the behavior is enforced for in-scope devices, and evidence it is consistently configured. MDM is the usual enforcement mechanism for managed fleets. ³

How do we handle shared devices (kiosks, shift devices)?

Treat them as high-risk if they leave controlled areas or store sensitive data. Enforce wipe/purge and pair it with operational controls like enrollment-only access and rapid re-provisioning, then document any availability constraints in exceptions. ³

What evidence is “enough” for an assessor?

A written decision record for scope/criteria/threshold, MDM configuration exports showing the setting and assignments, and a test record or logs demonstrating wipe/purge after failed unlock attempts. ¹

Footnotes

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

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

3. NIST SP 800-53 Rev. 5