EasyAccess SSO: sign-in as a control point
GitHub, AWS and the rest of your critical SaaS are reachable from any network on earth. No tunnel can stand in front of them. The one moment every access passes through is sign-in, so that is where the control goes, and that is where we look hardest at who is actually connecting.
- Protocols
- SAML 2.0 and OIDC, every realm
- Mode
- Own directory or broker
- Verdict
- Computed server-side only
The network stops at the edge of your estate
Everything a network control can protect, it protects well. The difficulty is that the systems your business now depends on most are not on your network at all.
A source repository, a cloud console, a payroll system. All of them are public services, deliberately reachable from any connection in the world. An attacker with valid credentials does not need to get past your perimeter, because there is no perimeter in the path. They just sign in.
That makes authentication the real boundary. And authentication is where most organisations know the least: a password, perhaps a second factor, and almost nothing about the browser presenting them.
What an identity provider can actually see
An identity provider has no agent on the device, so every signal it has is indirect. EasyAccess SSO treats that as an engineering problem rather than an excuse: it collects observations across seven layers, from the network path up to the way the machine executes code, and scores the contradictions between them.
A stolen password looks exactly like a correct one. The difference is in everything around it.
The signal pipeline is the distinguishing feature of this product, not a side feature. It exists because the alternative, trusting the credential, has been failing for a decade.
Replace your identity provider, or sit above it
The mode is a property of the realm, so one deployment can serve different parts of the organisation differently. Both modes are available from the first release.
Standalone
EasyAccess SSO is the directory. It holds the accounts, the password hashes (Argon2id), the TOTP secrets and the passkeys, and issues assertions and tokens directly to your service providers.
Broker
Keep Entra ID, Okta or Google as the source of identity. EasyAccess federates upward for the credential and adds its own second factor and policy on top, with no local passwords to manage or leak.
Hybrid
Both at once in a single realm, with the ability to apply policy resolved per subject rather than per realm, so contractors and employees can be governed differently without a second deployment.
Seven layers, one verdict
Each layer answers a different question, and each can be faked at a different cost. The value is not in any single layer. It is in what happens when two of them disagree.
Network and geography
Origin address, autonomous system, geolocation and whether the path looks like a hosting provider rather than a person's connection.
TLS handshake
A JA4 fingerprint of how the client negotiates TLS. Behind a corporate inspection proxy this fingerprints the middlebox, so it is used as cohort stability rather than as identity.
HTTP semantics
Header composition and ordering, and the Client Hints the browser is willing to assert. Cheap to collect, awkward to forge consistently.
JavaScript environment
What the browser says about itself: platform, locale, display and feature support. Taken as a claim to be checked, never as a fact.
WebAssembly probes
A small module measures how this machine executes code: integer and floating-point timing, cache layout. Hard to fake without actually being that machine.
Interaction behaviour
Timing characteristics of the sign-in itself, to separate a person from a script. Timings only, with no content captured and no profile of the individual built.
Cross-layer correlation
Contradictions are scored together: a browser claiming one platform while executing like another, or a TLS cohort that does not match the declared client.
The verdict is computed on the server. The browser submits discrete observations and never a conclusion. There is no client-side bypass switch of any kind, including for our own end-to-end tests, and there is a test that proves it.
Risk, not refusal
A contradictory profile does not lock anyone out. It asks for a passkey. Denial stays an explicit policy decision, so a false positive costs a user ten seconds rather than a support ticket and a lost morning.
A false-positive budget set in advance
Layered detection multiplies noise, and a step-up prompt that fires too often gets tuned to zero and stops being a control at all. The acceptable rate was fixed before the detection was written, not after complaints arrived.
Protocols, implemented properly
Both protocol frontends serve every realm, and a session established at one is a session at the other.
An identity provider is a target
Whoever controls the identity provider can become anyone in the company. The product is built on that assumption rather than around it.
Four eyes on the dangerous operations
Changing realm signing keys or claim mappings requires step-up authentication and a second administrator's approval, because whoever can edit a claim mapping can impersonate any employee.
Break-glass that leaves a mark
An emergency path exists for when policy or signals would lock everyone out. It is time-limited, heavily audited and impossible to use quietly.
Tamper-evident audit
The audit log is hash-chained with periodic checkpoints. Editing the record is an attacker's second move after taking an identity provider, so the record defends itself.
Replay defence
Assertion identifier caching, in-response-to validation, bounded clock skew and relay-state handling that will not become an open redirect.
Clock discipline
Time synchronisation is monitored and the health check fails when the node drifts, because assertion validity windows are only as trustworthy as the clock.
Rate limiting that spans the cluster
Credential stuffing, password spraying and user enumeration are throttled across every node, not per process.
Joiners, movers and the one that matters
The question a buyer asks first is rarely about provisioning. It is: someone was dismissed this morning. Kill their access to GitHub now.
That answer needs several things to be true at once, and they were designed in from the start rather than added later.
- Sessions are records in the database, each with an addressable identifier, so they can be found and terminated
- The session identifier is present in the very first token issued, so relying parties can act on it
- Single Logout propagates the sign-out to connected service providers
- SCIM deprovisioning removes or suspends the account at the SaaS provider itself
- Short identity provider sessions, with no silent re-authentication to paper over an expiry
Profiling with limits
Examining a browser this closely is a privacy question before it is a technical one, and employee consent is not a valid basis for it. The signal pipeline is built to be defensible to a regulator:
- Collection happens on the authentication path only, as a security measure strictly necessary to provide the service
- Behavioural signals are timings alone: no keystroke content, no profile of the person
- Browser identity is stored as a salted hash with a per-realm salt, never as raw identifiers
- Raw signals carry a short retention period; derived scores do not reconstruct them
- Impact assessment, legitimate-interest assessment and processing records are part of the product documentation, not an afterthought for your legal team
What it is made of
Bring sign-in under your own policy
Tell us which SaaS platforms carry your real risk and which identity provider you run today, and we will show you how EasyAccess SSO sits in that picture.