Security
Built so there is less to attack
The design removes the parts that usually get attacked: no port to open on the internet, no standing trust, no plaintext in the middle.
No inbound rules
Every agent dials out, so there is no port to open, forward or harden. A device that no rule connects to yours is never told it exists, so it cannot probe it.
Encrypted end to end
A fixed, modern cipher suite between the two devices, with keys that never leave them. A session stays encrypted the whole way, direct or relayed.
Deny by default
Joining the network grants nothing. Traffic moves only where a rule names two groups and a port.
Device requirements
Agent version, OS and expected country, checked every time the device connects rather than once at login. A device that falls short loses access.
Identity first
Members sign in with Google SSO or email and password, with a second factor where the organization requires one and passkeys where it allows them. Role and block status are read on every request, so blocking someone ends their access at once.
Append-only activity log
Who changed what, and when, including sign-ins and refused devices. Nothing in the product can edit or delete an entry, not even an admin.
What we can see
The control plane never carries traffic
The control plane hands each device its configuration, and the Discovery Service passes on the sealed messages two devices use to find each other. Neither can open your traffic.
Configuration down, state back
Down: the devices it may reach and the rules that apply. Back: online or not, plus the agent version and OS that device requirements check. Your traffic is not in that exchange.
Relays carry ciphertext
When a network refuses a direct path the session relays instead of failing. It passes through us encrypted, in a form we cannot read.
Separated by organization
Client, staging and production are separate networks under one login. A rule in one is invisible in another.
Assurance
Checked by people who are not us
Certifications and testing we hold today.
SOC 2 Type I
Independent report on the design of our security controls.
ISO 27001
Certified information security management system.
ISO 42001
Certified management system for responsible AI.
CREST Pathway+
Member of the CREST programme for assured security practice.
Annual penetration test
Third-party test each year. Summary available under NDA.
Mandatory two-factor
Every account with write access to content carries a second factor.
Uptime commitment
Business carries a 99.99% uptime SLA, written into the contract.
Documented in full
The connection model, the ports and every screen are in the docs.
Reporting a vulnerability
Report security issues to support@sxaccess.com. Please do not open a public issue for a vulnerability.
We acknowledge within one business day, give an assessment within five, and credit reporters who want it. We will not pursue legal action against good-faith research that respects user data and does not degrade the service.
What helps us move faster
- The affected surface: app or agent, dashboard, API, Discovery Service or relay, with the version if you have it.
- Steps to reproduce, and what you saw versus what you expected.
- Your assessment of impact, even a rough one.
- Whether you intend to publish, and when.
Please avoid
- Testing against organizations that are not your own.
- Anything that degrades the service for other people, including load and denial-of-service testing.
- Accessing, changing or keeping data that does not belong to you. Stop at the point the issue is demonstrated.
FAQ
Asked in security reviews
Can SXAccess read our traffic?
No. Sessions are encrypted between the two devices. The control plane only hands out configuration, and a relayed session passes through us in a form we cannot read.
Do we have to open any inbound ports?
No. Every agent dials out. There is nothing to forward and nothing to publish, and a device that no rule connects to yours cannot probe it.
What happens the moment someone leaves?
Block them in the dashboard. Role and block status are read on every request, so their access ends at once and the devices they signed in on disconnect. A device that stops meeting the device requirements loses access too.
Will the activity log satisfy an auditor?
The log is append-only: nothing in the product can edit or delete an entry, and service accounts appear under their own identity rather than a shared login.
Can we run the control plane inside our own perimeter?
No. SXAccess is hosted only, with no self-hosted edition and no published source. If that is a hard requirement, this is not the product for you.
How does a brand new device get trusted?
It does not. A device that joins reaches nothing until a rule names its group, and its device requirements are checked again every time it connects.
Found something? Tell us.
Write to support@sxaccess.com. One business day to acknowledge, five to assess.
Good-faith research is welcome