Follow the connection
Encryption has a beginning and an end.
For a node-routed private connection, WireGuard protects the device-to-node and node-to-destination tunnel legs. The routing node is a trusted part of that path. For a site gateway, traffic may then cross the local network before reaching the resource.
In the Publish model, HTTPS terminates at the public gateway. WireGuard carries traffic to the connector, which forwards it to the chosen application. For Outbound, the encrypted tunnel ends at the exit. Use HTTPS, SSH or another suitable application protocol wherever the complete application path needs protection.
Identity & secrets
An enrollment belongs to a resource and a workspace.
The person signing in, the enrolled device and a gateway are different identities. Workspace membership determines administrative scope; device approval and connection policy determine which resource can participate. A gateway has its own runtime credentials rather than reusing an endpoint’s identity.
Endpoint or gateway
Private key
Generated and retained locally by default.
Stays with the resourceBackend enrollment
Public identity
Public-key information binds the enrolled resource to its workspace.
Used to recognise the resourceRuntime credentials are scoped to the relevant device or gateway and its permitted operations. Private keys, access tokens, signing secrets and backend database credentials must not appear in browser code, CLI output, logs or support bundles.
Authority & execution
Being connected does not grant every kind of access.
Administrative permission
Who can enroll a device, change membership, approve a route or request public exposure? The backend checks the actor, resource ownership and entitlement.
Connection permission
Which destination, service or route is authorised for the resource? The supported local executor applies that approved scope under the device’s actual constraints.
The security design requires signed policy validation before privileged changes. Signature, resource identity, expiry, schema and version checks prevent an arbitrary UI request from becoming a route or DNS change. Local conflicts still matter, even when the request is authorised centrally.
Network permission does not replace application authentication. A private file server still needs appropriate accounts; a public portal still needs login and data permissions. An allowlisted source address establishes where traffic appears to come from, not who is using it.
Change & removal
Removal must reach the components that enforce it.
Withdraw the relevant grant, allow the enforcing runtime to observe and apply the change, then verify actual reachability. Network revocation does not erase data or replace application-session recovery.
How revocation and lost-device recovery work
Revoking a device stops new authorised policy and removes the relevant peer from gateway desired state. Disabling a published service or removing a route changes its authorised configuration. The endpoint and gateway then need to observe and apply that change; policy expiry also limits stale authorisation.
Verify the observed result and actual reachability. Do not assume instant removal from a disconnected device, immediate termination of every session or identical behaviour across native runtimes. Compatibility Mode needs its own assessed removal procedure because it does not refresh managed endpoint policy.
For a lost device, use the supported revocation process and assess application sessions and credentials separately. Revoking a network identity is not a remote wipe and does not remove data already copied to the device.
Shared responsibilities
The platform carries the connection. Your team still owns the resource.
Scroll sideways to compare responsibilities.
| Layer | Responsibility | What to verify |
|---|---|---|
| Fibmesh policy and delivery | Authorise scope, distribute configuration and report execution | Product, runtime and gateway enforcement for the deployed release |
| Your endpoint or site | Protect credentials, maintain software and control local networking | Host firewall, permissions, route conflicts and secure updates |
| Your application | Authenticate users and control data access | Login, patching, backups and application encryption |
| Your operations team | Review access and investigate changes | Ownership, removal, redacted diagnostics and relevant audit evidence |
Sensitive changes should produce audit evidence; diagnostic data must exclude secrets. The current model is not a promise of a SIEM integration, packet-content logging policy or complete live monitoring. Published retention and handling details belong in the trust documentation.
Read about data and logging →Security questions
Know the scope of the protection.
Is every Fibmesh connection end-to-end encrypted?
No blanket claim applies. WireGuard encrypts each configured tunnel leg. Node-routed paths and Publish have gateway termination points. Application encryption can protect content across those intermediate points.
Is Fibmesh an application firewall or malware scanner?
The managed firewall controls supported network-level exposure. It does not validate application code, scan files or replace endpoint protection and application security controls.
Are these controls independently certified?
This section explains the architecture and required controls. It does not claim an independent audit, ISO or SOC certification, a compliance suite or a response SLA. Use the Trust centre for published evidence and reporting routes.