Should organisations allow custom scripts on travel networking devices?

Why This Matters for Security Teams

Allowing custom scripts on travel networking devices creates a security and support problem, not just a configuration preference. The moment a script changes routing, firewalling, DNS handling, or telemetry, the device is no longer operating as a standard managed asset. That raises questions about change control, rollback, accountability, and whether the device can still be trusted during an incident. For teams using remote access controls, the risk is amplified because travel devices often sit between untrusted networks and corporate resources.

This is where NIST SP 800-207 Zero Trust Architecture is useful: the model assumes no implicit trust based on network location, so a device that can self-modify should be evaluated as part of the trust boundary, not outside it. The issue is not whether scripting is technically possible, but whether the organisation can prove the script does not weaken policy enforcement, inspection, or recovery. In practice, many security teams encounter this only after a travel device fails in the field and no one can tell whether the script, the network, or the underlying firmware caused the outage.

How It Works in Practice

The safest way to think about custom scripts on travel networking devices is as a controlled exception. If the script is needed for a very specific workflow, it should be tied to an owned use case, version-controlled, and included in the same approval process as any other configuration change. That means documenting what the script does, which interfaces it touches, what dependencies it has, how it is validated, and how it is removed if something goes wrong.

Operationally, the script should not be treated as a convenience feature if the device supports enterprise connectivity. Instead, it should be handled like a managed extension of the device baseline. A good control set usually includes:

• Named owner and business justification
• Peer review before deployment
• Recovery steps that work without the script
• Logging that captures script execution and config changes
• Periodic revalidation after firmware updates or network changes

From a cyber risk perspective, scripts can create hidden dependencies on local privileges, stored secrets, or undocumented system calls. They may also interfere with monitoring or break assumptions made by network access controls. CISA guidance on secure configuration management and CISA Zero Trust Maturity Model both reinforce the same practical point: you need known state, observable behaviour, and a way to recover fast when something drifts. If the device is used by executives, incident responders, or field staff in constrained environments, that discipline matters even more because troubleshooting time is usually limited. These controls tend to break down when the script depends on undocumented vendor behaviour or when device firmware updates silently change execution order because the recovery path is no longer predictable.

Common Variations and Edge Cases

Tighter script controls often increase setup time and support overhead, requiring organisations to balance flexibility against operational stability. That tradeoff is real for consultants, journalists, engineers, and incident responders who need temporary device behaviour that standard profiles do not cover. In those cases, a limited pilot exception can make sense, but current guidance suggests the exception should be time-bound and reviewed like any other unmanaged change.

There is no universal standard for this yet, especially for travel networking devices that blend consumer simplicity with enterprise use. Some organisations allow only signed or pre-approved scripts, while others prohibit all custom automation unless the device is enrolled in formal endpoint or network management. The stronger the security requirements, the less tolerance there should be for opaque scripting, especially if the device handles authentication, tunnels sensitive traffic, or bridges to internal systems. Where the device is part of a broader remote access stack, the question also intersects with identity and session trust: a script that weakens certificate handling, token storage, or VPN policy can undermine otherwise sound controls. For that reason, NIST CSF and OWASP guidance on secure configuration are often more relevant than feature-level vendor advice. In practice, the hardest failures are not malicious scripts but forgotten ones that outlive the travel use case and remain active long after the original owner has moved on.

Related resources from NHI Mgmt Group

• Should organisations allow contractors to access sensitive systems from personal devices?
• Should organisations allow AI agents to use hardcoded secrets?
• Should organisations allow AI systems to execute response actions directly?
• When should organisations prefer standards over custom implementations?