Trust on someone else's network

Remote access to a field device crosses boundaries between the network owner, Dataplicity, your organisation, and the Linux machine. A production design must make each boundary explicit.

Operating connected products series

1. After devices ship
2. One device record from factory to field ticket
3. Dataplicity beside your existing stack
4. From signal to verified recovery
5. Trust on someone else's network

This security model explains the controls Dataplicity provides, the permissions the network and device owner retain, and the assumptions an operator must verify. It is architecture guidance, not a substitute for your organisation's threat model or contractual security review.

Start with four control boundaries

Boundary	Primary control
Deployment network	Network owner approves the device and permits the required outbound destinations
Dataplicity platform	Device credential, individual account, organisation scope, roles, and supported confirmation controls
Linux device	Agent service identity, groups, ACLs, sudoers, credentials, and service configuration
Device-hosted application	Its own authentication and authorisation when reached through Wormhole

Passing one boundary does not bypass the next. In particular, platform permission to request a command does not turn that command into Linux root, and a Wormhole route does not authenticate the application behind it.

Outbound connection model

The Dataplicity agent initiates and maintains an outbound encrypted connection to Dataplicity. The Dataplicity access path does not require an inbound port-forwarding rule for SSH, RDP, or a device-hosted web service.

In practice:

• the network owner must authorise the deployment and permitted outbound traffic
• restricted networks may need the documented Dataplicity destinations allowlisted
• NAT and changing public addresses do not require a per-device inbound route
• the device may still run local services; their listening interfaces and host firewall remain the device owner's responsibility
• applications reached through Wormhole retain their own authentication and security model

The outbound model removes the need to expose an inbound service for Dataplicity access. It does not make the device, its local services, credentials, operating system, or deployment network risk-free.

See How it works for the connection components and Firewall requirements for required destinations.

Device identity

Each provisioned device has a Dataplicity identity and presents credentials associated with that identity and organisation. The service uses those credentials to authenticate the connecting agent.

Protect device credentials as secrets. A copied credential can undermine the relationship between the stored identity and the physical machine presenting it. Keep provisioning material out of source control and customer-readable images, restrict access during manufacturing, rotate after suspected exposure, and verify the replacement path before revoking the old credential.

Device authentication establishes which Dataplicity identity presented a credential. Your provisioning and asset process must maintain the relationship between that identity, the intended hardware, product class, customer, and site. See One device record from factory to field ticket.

Authentication

• Account login - email and password with optional two-factor authentication (2FA guide)
• SAML SSO - available when the organisation's current entitlement enables it
• SCIM - available when enabled for the organisation; user, group, and direct-role options are configured separately

Enable 2FA on all accounts with device access.

Team access

Use teams instead of sharing account passwords. Each team member has their own login. Remove team members when they leave - access is revoked without rotating shared credentials.

Permissions

Control who can access which devices through team membership and account roles. Apply least privilege: give support access to production devices, restrict development device access to engineering.

Platform access and device permissions are separate

Dataplicity roles, team membership, API scopes, and confirmation steps decide who may request an action. Linux permissions on the device decide what that action can do. Passing a platform authorisation check does not turn a command into a Linux root command.

Device-side privilege boundary

The standard installer creates a dedicated dataplicity OS account and configures the interactive agent to run as that account. Its home and remote-file directory are owned by that account. The agent executable and service configuration are installed by an administrator, but the terminal process is started under the configured service identity.

The security principle is:

Dataplicity's device-side access is bounded by the permissions granted to its OS identity. Operators retain control of that boundary.

Remote terminal sessions, remote file operations, fleet commands, and operator-confirmed AI-assisted terminal or fleet commands use the agent command path. They inherit the agent's effective Linux user, groups, filesystem access, credentials, ACLs, and service policy. They do not inherently gain privileges because the command came through Dataplicity or was suggested by AI.

Wormhole forwards network traffic to a service on the device. The forwarded application keeps its own process identity and authorisation model. Wormhole does not change the agent account's Linux permissions.

Some package-managed, fixed-function maintenance components can use separately configured system service identities. Review those service units independently. They do not give the general terminal, file, fleet-command, or AI-assisted command path unrestricted access.

Administrator-controlled exceptions

An administrator can deliberately expand the boundary by:

• adding dataplicity to supplementary groups
• granting filesystem ACLs or changing file ownership and modes
• allowing selected commands through sudoers
• changing the agent service user, group, capabilities, or sandbox settings
• making device credentials or privileged helper scripts available to the account

The classic installer includes a narrow passwordless sudo rule for the agent's device-reboot action. It does not grant general passwordless sudo. Custom images and older or modified installations may differ, so inspect the effective configuration on each fleet.

Running the agent as root, granting broad groups, or allowing blanket passwordless sudo means remote terminal and automation paths can exercise those added permissions. Treat that as an explicit administrator-controlled exception with a larger risk and audit scope.

Verify the effective boundary

From a Dataplicity terminal, check the identity and memberships with id and review access to a representative file or service. On the device console, also review the agent process owner, service configuration, supplementary groups, ACLs, and applicable sudoers entries. Test on the same image and release used in production.

The behaviour above is based on the production agent implementation:

• terminal processes inherit the configured service identity
• file reads and command execution run inside the agent process
• the current production agent release

Audit trail

Dataplicity records supported operational access and platform events. Coverage, fields, retention, and export options depend on the action and organisation configuration. Review the relevant product history before relying on it for an assurance requirement.

An incident can span Dataplicity, the Linux device, an external service desk, and customer communication. Keep the identifiers and timestamps needed to correlate those records instead of assuming that one timeline captures every command, device-side side effect, or external action.

See Audit trails and Audit access.

Access revocation

Choose the revocation that matches the compromised boundary:

• remove or suspend the individual user and review team membership
• rotate affected account or API credentials
• rotate device or provisioning credentials after suspected exposure
• disable or uninstall the agent when a device leaves management
• remove application credentials and access separately for services exposed through Wormhole

Revoking a Dataplicity user does not rotate credentials stored on the Linux device. Uninstalling the agent does not revoke an unrelated application account. Include both platform and device-side assets in the response.

What this model does not decide

Dataplicity controls do not replace:

• secure boot, operating-system patching, disk encryption, or application hardening
• the network owner's approval and egress policy
• safeguards for secrets readable by the agent's Linux identity
• authentication inside an application reached through Wormhole
• the organisation's approval, safety, and change-management process
• contractual security, availability, recovery, or data-residency requirements

Review Security and compliance for the current certification posture and Data residency for deployment locations and regional limits.

Least privilege guidance

• Give each team member an individual account
• Use teams to scope device access by role
• Enable 2FA on all accounts
• Keep the dataplicity account unprivileged
• Grant only the specific group, ACL, service, or command access required
• Avoid blanket passwordless sudo and unrestricted privileged helper scripts
• Review group, ACL, service, and sudoers changes as security-sensitive configuration
• Protect device credentials, provisioning material, and scripts readable by the agent account
• Test the effective identity and permissions after image, installer, or service changes
• Uninstall the agent on decommissioned devices
• Secure applications exposed via Wormhole with their own authentication (securing Wormhole services)

Production security recommendations

1. Include the agent in your golden image for repeatable device installation
2. Apply the approved device class and customer, site, and operational context during the ownership handoff
3. Configure NTP on devices without a hardware RTC
4. Review firewall requirements with customer IT where networks are restricted
5. Use Wormhole only for services that need external access; authenticate at the application layer
6. Verify the agent's effective Linux identity and permissions on the production image
7. Review supported audit records and retention against the organisation's evidence requirements

When to use Dataplicity vs direct SSH/VPN

Scenario	Recommendation
Device in a customer network you do not control	Dataplicity - no per-device inbound route; agree and permit the required outbound destinations
Device on your own lab network	Direct SSH may be simpler for engineering-only access
Corporate office infrastructure	Corporate VPN may already be the standard
Production fleet across many customer sites	Dataplicity - consistent access model without per-site VPN setup
Assurance requires access records	Review Dataplicity's supported event coverage and retention against the exact requirement

Dataplicity and direct SSH/VPN are not mutually exclusive. Many teams use Dataplicity for field devices and direct SSH for lab hardware.

Security review path

For a production assessment:

1. Confirm the current security and compliance posture.
2. Review data residency and current subprocessor information.
3. Validate firewall requirements with the network owner.
4. Map individual accounts, teams and permissions, SSO and SCIM, and API keys to your access policy.
5. Inspect the agent identity, groups, ACLs, sudoers, credentials, and services on the production image.
6. Authenticate every device-hosted application exposed through Wormhole.
7. Rehearse user, API-key, device, and application-access revocation.
8. Compare supported audit coverage and retention with contractual and incident-response needs.

For a questionnaire, architecture discussion, data processing agreement, or current subprocessor information, follow the contact path on Security and compliance.

Continue the series

Return to After devices ship for the complete operating model, or connect one supported device and test the path under the permissions you intend to use in production.

Related

• Security and compliance
• Data residency
• Firewall requirements
• Dataplicity beside your existing stack
• Support access
• Teams and permissions
• Remote shell privilege guidance