Security model

Remote access to field-deployed devices is sensitive. This page explains how Dataplicity handles connections, identity, and access control - without vague security claims.

Outbound connection model

The Dataplicity agent on each device initiates and maintains an outbound HTTPS connection to Dataplicity. The device does not listen for inbound connections from the internet.

This means:

• No inbound port forwarding on customer routers
• No firewall exceptions for SSH, RDP, or other inbound services
• Devices behind NAT and restrictive firewalls can still connect
• The attack surface on the device is not increased by opening ports

See How it works for the full architecture.

No inbound port forwarding required

Unlike traditional SSH or VPN access, Dataplicity does not require you to expose services on the public internet. All access is routed through the existing outbound agent connection.

Device identity

Each device is identified by a unique serial number assigned during agent installation. The agent authenticates to Dataplicity using credentials tied to your account and that device identity. Devices cannot impersonate other devices.

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 authorization 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 authorization 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 behavior 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 operational access events. Review who accessed which devices and when. See Audit trails.

Access revocation

To revoke access:

• Remove a user from a team
• Disable or uninstall the agent on a specific device
• Rotate account credentials and enable 2FA if a shared password was compromised

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 customer/site tags during imaging for access scoping
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. Review audit trails regularly for unexpected access patterns

When to use Dataplicity vs direct SSH/VPN

Scenario	Recommendation
Device in a customer network you do not control	Dataplicity - outbound connections work without customer firewall changes
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
Compliance requires access logging	Dataplicity - audit trail of operational access

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

Related

• Security and compliance
• Data residency
• Firewall requirements
• Port forwarding compared
• Support access
• Teams and permissions
• Remote shell privilege guidance