Only place a control on the device when the objective truly depends on local execution and the resulting access can be tightly limited. If the same outcome can be achieved through policy, baseline requirements or server-side enforcement, a mandatory app usually adds unnecessary trust and privacy exposure.
When should a control live on the device, and when should it not?
A device-resident control is justified when the security objective depends on something only the endpoint can see or enforce locally, such as hardware-backed trust, on-device attestation, or protections that must remain available without a network round trip. If the same result can be enforced centrally, prefer policy, baseline configuration, or server-side checks because they are easier to govern and less invasive.
Putting logic on the device increases the trusted computing base, so every local control should earn its place by changing the security outcome in a way central enforcement cannot. The more that control depends on the endpoint, the more you must accept heterogeneity, patching burden, and privacy impact as part of the design trade-off.
What makes device-local enforcement appropriate?
The best candidates are controls that need local context, local signals, or local enforcement at the point of use. Examples include device posture checks, disk or key protection, secure boot and attestation, and controls that must continue to work offline or during degraded connectivity. That is why device trust matters more for device and IoT identity than for ordinary policy decisions.
Device-local control is also appropriate when the endpoint is the only place that can protect a sensitive capability from user tampering or application bypass. If the control can be bypassed by uninstalling an app, denying permissions, or spoofing a client-side check, it is usually not a strong security boundary unless the platform itself enforces it. For that reason, hardening guides such as CIS Benchmarks remain the right model for many endpoint decisions.
When a control is fundamentally about authentication, device trust, or key material, the device can be the right anchor point, but only if the implementation is resistant to export, replay, and downgrade. A local control that merely adds friction without materially improving assurance should be treated as an experience cost, not a security gain.
What belongs elsewhere instead of on the device?
If the control is really about policy consistency, entitlement, or allowed behaviour across many users and systems, moving it into the app or OS often creates duplicated logic and inconsistent enforcement. Server-side authorization, configuration baselines, and managed policy are usually better for decisions that should not vary by endpoint state or user manipulation. Well-designed control catalogs such as NIST SP 800-53 Rev 5 Security and Privacy Controls help teams separate enforcement points from the objective itself.
Device installation also makes poor sense when the control would collect more data than the security outcome justifies. A mandatory app that requires broad device permissions, persistent sensors, or invasive telemetry can create privacy and trust concerns that exceed its value. If a server-side rule, platform setting, or network control can achieve the same result, the simpler control is usually easier to explain, audit, and retire.
Centralised enforcement is especially preferable when the main need is consistent baseline protection rather than bespoke endpoint logic. That is the basic logic behind NIST Cybersecurity Framework 2.0, which pushes organisations to choose controls that are governable, measurable, and resilient at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Endpoint control placement affects consistent secure configuration and account enforcement. |
| Recommendation — Use CIS-5 to keep endpoint controls centrally governed and consistently enforced. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Device-local controls are often a configuration choice that should be justified against managed baselines. |
| AC-6 — Least Privilege | Local controls should only exist when they truly reduce privilege or limit access on the endpoint. | |
| Recommendation — Apply CM-6 to prefer managed baselines over bespoke device logic where possible. Use AC-6 to keep endpoint-executed controls narrowly scoped to the minimum needed authority. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The decision hinges on whether local enforcement is needed for access control at the device boundary. |
| Recommendation — Map device-resident enforcement to PR.AA-05 only when the endpoint materially controls access. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Choosing endpoint versus central enforcement is a configuration governance decision. |
| Recommendation — Use A.8.9 to control and justify endpoint-level security configuration changes. | ||
Practitioner Guidance
What to prioritise: Start by asking whether the control needs local execution to achieve its security purpose, or whether the same objective can be met with centrally managed policy, posture requirements, or server-side authorization. If the answer is no local dependency, default away from a mandatory app.
What to verify: Confirm that the device control cannot be meaningfully bypassed by user removal, app tampering, configuration drift, or unsupported platforms. Also verify that the control still produces the desired security state when the device is offline, partially managed, or out of compliance.
Common mistake: Teams often confuse “runs on the device” with “is more secure.” In practice, a local control is only stronger when it adds a real enforcement boundary, not when it simply duplicates policy in a more fragile place.
Practitioner takeaway: Put controls on the device only when local authority is essential to the security outcome and the endpoint can be trusted enough to enforce it without creating disproportionate privacy, maintenance, or bypass risk.
Related resources from NHI Mgmt Group
- How do organisations decide when DNS belongs in security architecture reviews?
- How do organisations decide whether to standardise on one agentic AI security control model?
- How should organisations decide where AI belongs in offensive security workflows?
- How should organisations decide where microsegmentation belongs in the control stack?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org