Security & trust boundaries
Know who can connect and where encryption ends.
Device identity, connection permission and encryption have different jobs. Follow the boundaries, protect local keys and keep application access under your control.
Visit the Trust centre ↗Post-quantum work · In development ↓01 / Follow the connection
Encryption has a beginning and an end.
Start with the path your traffic takes. A tunnel protects its own leg; each termination point and the final application hop have their own security responsibilities.
The routing node is part of the trust boundary.
- Enrolled deviceLocal private keyStarts here→WireGuard
- Fibmesh routing nodeTunnel terminationTunnel termination→WireGuard
- Enrolled serverApplication authenticationApplication boundary
Each tunnel leg is encrypted. This node-routed path is not a single device-to-device encrypted tunnel.
Use application encryption such as HTTPS or SSH when you need protection through intermediate routing points. A site gateway adds a final LAN hop that needs its own protection.
A public web request crosses two encryption boundaries.
- VisitorBrowser or API clientStarts here→HTTPS
- Publish gatewayHTTPS terminates hereTunnel termination→WireGuard
- Host / Edge connectorWireGuard terminates hereTunnel termination→Configured app hop
- ApplicationLocalhost or selected LAN hostApplication boundary
The gateway selects the application by hostname. The app handles visitor login or API authentication.
The application hop may be local or cross a LAN; secure it appropriately. A tunnel does not make an unprotected web application safe to publish.
The tunnel protects the path to the exit.
- Your deviceStarts the requestStarts here→WireGuard
- Fibmesh exitTunnel terminationTunnel termination→HTTPS / other app protocol
- Internet serviceApplication encryption continuesApplication boundary
Beyond the exit, protection depends on the protocol used by the application.
An exit address is a routing identity, not proof that a user is authorised. Full-tunnel configuration does not itself establish a verified kill switch or protection for every platform exception.
For a node-routed private connection, the routing node is trusted. A site gateway can add a local-network hop before the resource. For Publish, protect the connector-to-application hop. For Outbound, application encryption and authentication still apply beyond the exit.
These are illustrative boundaries. They explain the connection model and required protections; they do not demonstrate enforcement for a deployed release.
02 / Identity & secrets
A local secret. A public identity.
An enrollment belongs to a resource and a workspace. The person signing in, an enrolled device and a gateway are different identities.
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 resourceGive each credential a purpose.
Interactive sessions, enrollment credentials and runtime credentials have separate permissions. Runtime credentials are scoped to the relevant device or gateway and its permitted operations. A gateway uses its own runtime credentials rather than reusing an endpoint’s identity.
Keep secrets out of diagnostics.
Private keys, access tokens, signing secrets and backend database credentials must not appear in browser code, CLI output, logs or support bundles. Endpoint and gateway private keys remain local by default.
03 / Authority & execution
Four questions. Separate permissions.
Recognising a resource, administering it, reaching it and signing in to its application are separate decisions. Being connected does not grant every kind of access.
04 / Change & removal
Removal must reach the enforcer.
Withdraw the relevant grant, let the enforcing runtime observe and apply the change, then verify actual reachability. Network revocation does not replace application-session recovery.
- 01
Withdraw
Remove the relevant device, service or route authorisation.
- 02
Observe & apply
The endpoint and gateway must receive and enforce the changed configuration.
- 03
Verify
Check the observed result and test the resource’s actual reachability.
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 the change; policy expiry also limits stale authorisation.
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 delete data already copied to the device.
05 / Shared responsibilities
Your team still owns the resource.
Fibmesh carries the connection. Secure endpoints, applications and operating practices complete the path.
Scroll sideways to compare responsibilities. Focus the table and use the arrow keys on a keyboard.
| 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. This model does not promise a SIEM integration, complete live monitoring or a packet-content logging policy. Published retention and handling details belong in the trust documentation.
Read about data and logging →In development
Quantum-resistant tunnels.
Fibmesh is implementing post-quantum protection for tunnel connections. This work is in development; it is not a claim that current connections are post-quantum secure.
The current tunnel model uses WireGuard. Algorithm, composition, deployment availability, supported platforms, timing and release scope remain unspecified and require separate confirmation. The existing tunnel boundaries and application security responsibilities continue to apply.
Security questions
Know the scope of the protection.
Use the Trust centre for published evidence and reporting routes.
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.
Review the evidence behind the connection.
Visit the Trust centre ↗