How should teams secure smart devices that use companion apps and remote access?

Treat the device and its companion app as one identity surface. Use unique credentials, enable MFA, restrict remote administration, and keep firmware current. If the device cannot support those controls, remove it from trusted access paths. The key is to reduce both account reuse and network reach, because either one can turn a simple device into a persistent foothold.

Why This Matters for Security Teams

Smart devices with companion apps are rarely just “devices.” They are a coupled identity and control plane: the hardware, the mobile app, the cloud service, the remote admin channel, and often a shared backend account. That means compromise can begin with an app login, a reused password, a weak API token, or an overexposed remote access feature, then end with persistent device control. The most common mistake is treating the device as a network asset while ignoring the identity paths that actually govern it.

This is why NHI Management Group consistently frames connected-device risk as an identity problem, not only an IoT problem. In its Ultimate Guide to NHIs, NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which is a useful proxy for how often hidden machine access escapes governance. In practice, many security teams discover remote control exposure only after an account reuse event or cloud takeover has already created a durable foothold.

How It Works in Practice

The safest model is to treat the device and its companion app as one identity surface with distinct control points. The device should have its own unique credential or certificate, the companion app should authenticate users separately, and remote access should be mediated by a central policy layer rather than direct internet reach. Where possible, use short-lived secrets, per-session authorization, and revocation that is tied to device state, not just user password resets.

That approach aligns with the direction of the OWASP Non-Human Identity Top 10, which emphasizes that machine credentials require lifecycle controls, rotation, and visibility. It also maps to the operational guidance in Ultimate Guide to NHIs, especially where devices depend on backend tokens, API keys, or remote management agents. Practical controls usually include:

• Unique device enrollment, never shared admin accounts.
• MFA for the human account that approves remote access.
• Remote administration disabled by default unless there is a documented business need.
• Firmware and companion app updates tracked as a security dependency, not a convenience task.
• Network segmentation so the device cannot laterally reach internal systems.

For higher-risk deployments, current guidance suggests pairing this with centralized policy enforcement and device posture checks before any remote session is granted. Remote access should expire automatically, and privileged actions should be logged in a way that links user intent to device state. These controls tend to break down in consumer IoT environments where the vendor requires always-on cloud relay, hard-coded backend tokens, or unverifiable firmware update paths.

Common Variations and Edge Cases

Tighter device access often increases user friction and support overhead, requiring organisations to balance convenience against containment. That tradeoff is especially visible in home office deployments, shared family devices, and third-party managed equipment, where the business owner wants remote convenience but security teams need revocation and auditability.

Best practice is evolving for devices that cannot support MFA, certificate-based identity, or meaningful session expiry. In those cases, the least risky option is often to remove the device from trusted access paths entirely and keep it off sensitive networks. The same caution applies to vendor-maintained mobile apps that request broad permissions or reuse long-lived tokens across multiple devices. If the companion app cannot be isolated from personal credentials, it should not be treated as enterprise-safe remote access.

This is also where the identity model matters more than the checkbox list. The OWASP Non-Human Identity Top 10 and NHI Mgmt Group’s research both point to the same operational reality: once machine access is shared, overprivileged, or hard to revoke, the device becomes a persistent foothold. That risk is amplified when remote functions are exposed through third-party cloud services, because revocation may depend on vendor workflows instead of local policy. In those environments, governance should prioritize isolation, replacement, or decommissioning over trying to harden an unmanageable control path.

Related resources from NHI Mgmt Group

• Which frameworks should teams use to assess OT secure remote access governance?
• How should teams secure non-human identities across cloud and SaaS?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams combine SAST and DAST in a secure development programme?