Device lock and wipe are remote administrative actions used to protect managed endpoints when a device is lost, stolen, or returned during offboarding. Locking restricts access, while wiping removes data from the device. In MDM environments, these controls support rapid containment of sensitive information and reduce exposure from unmanaged hardware.
Expanded Definition
Device lock and wipe are remote containment actions for managed endpoints, but their purpose is broader than lost-phone recovery. In NHI and agentic operations, they are part of a lifecycle control set that helps reduce exposure when a device used for administrative access, credential storage, or agent execution is no longer trusted. Locking preserves the device for later review, while wiping removes data and, in stronger implementations, resets local trust state. No single standard governs the exact trigger conditions for these actions across mobile device management and endpoint management platforms, so the policy definition must be explicit.
These controls sit alongside identity governance and recovery planning rather than replacing them. A wipe does not fix overbroad access, stale tokens, or poor offboarding, and a lock does not prevent offline data exposure if secrets were already cached locally. The NIST Cybersecurity Framework 2.0 provides a useful governance lens for protecting assets and containing incidents, while NHIMG guidance on the Ultimate Guide to NHIs emphasizes lifecycle discipline around access revocation and exposure reduction. The most common misapplication is treating wipe as a substitute for credential revocation, which occurs when teams assume device sanitisation also invalidates every token, key, or session tied to the endpoint.
Examples and Use Cases
Implementing device lock and wipe rigorously often introduces operational friction, because the same action that protects sensitive data can also erase evidence or interrupt legitimate recovery, so organisations must weigh rapid containment against forensic and continuity needs.
- A laptop used by an NHI operations engineer is reported stolen after an incident response shift. Security locks the device immediately, then wipes it once logs and ownership checks confirm no forensic hold is required.
- An employee returns a tablet used for approving service-account changes during offboarding. The device is wiped after confirming all local certificates, cached credentials, and business data have been migrated or revoked.
- An autonomous agent controller runs from a managed endpoint in a test lab. If the endpoint leaves the approved network zone, a lock prevents further use until the device is re-enrolled and validated under NIST Cybersecurity Framework 2.0-aligned controls.
- Endpoint teams use lock first when a device may still contain information needed for investigation, then wipe only after the preservation decision is complete.
- A lost BYOD device that held cached access to a secrets portal is remotely wiped because the organisation can no longer trust local storage or session state.
These scenarios map to the broader NHI lifecycle described in the Ultimate Guide to NHIs, where device actions support containment but do not replace identity-level remediation.
Why It Matters in NHI Security
Device lock and wipe matter because compromise often begins at the endpoint, where cached credentials, tokens, certificates, and administrative sessions can survive longer than expected. If a device that touches NHI workflows is lost, stolen, or reused without sanitisation, an attacker may inherit a path into automation pipelines, secrets stores, or privileged consoles. That is why device actions must be paired with token revocation, certificate invalidation, and post-incident review, not treated as a standalone security outcome. NHIMG reports that 91.6% of secrets remain valid five days after notification, which shows how slowly many organisations remediate exposure when identity and endpoint controls are not coordinated, according to the Ultimate Guide to NHIs.
For governance, this term connects directly to containment, asset protection, and recovery discipline in NIST Cybersecurity Framework 2.0. The operational lesson is simple: a wiped device is only safe after the identities and sessions it carried have been cut off as well. Organisations typically encounter the real need for device lock and wipe only after a laptop, tablet, or admin workstation is lost or repurposed, at which point the control becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and lifecycle containment tied to endpoint loss. |
| NIST CSF 2.0 | PR.DS | Protects data at rest and during containment actions on managed devices. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust assumes device trust can be revoked when posture changes. |
| NIST SP 800-63 | IAL2 | Identity assurance depends on controlling devices that store or use authenticators. |
| CSA MAESTRO | Agentic systems need endpoint containment when control planes or runners are compromised. |
Revoke local credentials and verify device sanitization when endpoints used for NHI access are lost or offboarded.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
