Three control points, one set of rules
EasyAccess is not a suite assembled from acquisitions. Each product exists because a specific kind of access could not be governed by the others, and they are built by one team to the same engineering standard.
What covers what
The products overlap less than you would expect, because they intervene at different points: the network path, the device, and the moment of authentication.
| The access you need to govern | ZTNA | RBI | SSO |
|---|---|---|---|
| Internal application, managed device | ✓ | – | Authentication |
| Internal application, unmanaged device | – | ✓ | Authentication |
| Public SaaS such as GitHub or AWS | Network pinning | Optional | ✓ |
| Browsing the open web from a corporate device | – | ✓ | – |
| Privileged administrative consoles | Path control | Optional | ✓ |
| Third-party contractor, short engagement | Optional | ✓ | ✓ |
Each product is sold and deployed independently. Nothing here requires you to buy all three, and none of them depends on the others to function.
Closing the gap that identity alone leaves open
There is one place where two of these products combine into a control neither can provide on its own, and it answers the hardest question about SaaS security.
An identity provider governs the moment of sign-in. It does not govern the hours afterwards, because the session then lives at the SaaS provider, outside anything you operate.
The lever that does reach inside those hours is network-based, and the major platforms provide it: GitHub supports an IP allow list, and AWS policies can be conditioned on source address or VPC endpoint. The obstacle has always been that a distributed workforce has no stable set of addresses to put on such a list.
EasyAccess ZTNA supplies exactly that. Its egress addresses are fixed and known, so they can populate the allow list at the SaaS provider. Sign-in is then policed by EasyAccess SSO, and the session that follows is only reachable from inside your tunnel.
A stolen credential used from an attacker's own connection fails at the network check even if it passes the password. A session hijacked after sign-in cannot be used from anywhere you have not allowed.
The user signs in through EasyAccess SSO
Policy, factors and the browser signal pipeline all apply at this moment.
Their traffic leaves through EasyAccess ZTNA
From a known, fixed set of egress addresses that you control.
The SaaS provider accepts only those addresses
Through its own allow-list mechanism, enforced on every request rather than only at login.
Departure is handled at both ends
Sessions terminated and logout propagated by SSO, the account removed at the provider through SCIM.
Standards work on continuous session signalling is progressing, but support across the major platforms is not something we will promise before it exists. The network lever works today.
The same operational foundation
Whichever products you run, your administrators meet the same patterns and your auditors meet the same evidence.
Self-hosted, always
There is no vendor cloud in the data path of any product. You deploy into your own infrastructure or your own cloud account, including air-gapped environments.
Audit as a first-class record
Every product writes a complete trail, refusals included, with retention controls and export. Investigation data is kept separate from the audit record itself.
Role-based administration
Granular permissions, separate administrative authentication and enforced multi-factor sign-in for anyone who can change policy.
Clustered by design
High availability without a split brain: shared state in PostgreSQL, distributed coordination for scheduled work, and health probes that tell the truth.
Geographic and temporal controls
Location filtering and schedule-aware access appear consistently, so a policy written in one product reads the same way in another.
One vendor, one escalation path
The same engineering team builds all three. When something spans two products, there is nobody to point at.
What this platform does not claim
Security products are easy to oversell, and the cost of doing so lands on the buyer during an incident rather than during a demo. So, plainly:
- Platform patterns are shared by convention between the products, not by a common runtime. The products version and ship independently, which is a deliberate trade of integration depth for release safety.
- An identity provider controls authentication, not what a SaaS application does with the session afterwards. The network pinning described above is a mitigation, not a cure.
- Browser isolation protects the endpoint from the web. It is not a data loss prevention product, although clipboard and file transfer controls cover the obvious paths.
- Control frameworks are mapped and evidenced, but mapping is not certification, and we say which is which.
Start where the risk is
Most organisations adopt one product first and add the others when the next gap becomes the loudest one. We are happy to say which one that should be.