InstaSafe
Book a demo
Single sign-on

Single sign-on for cloud and private apps

Single sign-on (SSO) lets people sign in once, with one set of credentials, and open every application they are allowed to use.

InstaSafe checks MFA and the device at that one sign-in, then carries it to your SaaS apps, to internal apps that never touch the internet, and to the Windows desktop — under one access policy. Already run Microsoft Entra ID or Okta? InstaSafe works behind it.

Try the sign-in simulator ↓
Checked at the doorMFA and a device check run on the one sign-in, every time — not as a second portal afterwards.
Keeps your providerUse InstaSafe as your identity provider, or behind the Entra ID, Okta or Google you already run.
Off in one stepDisable a leaver once: refused everywhere, and cut immediately on private apps behind the gateway.
The problem

Three risks that come with a password per app.

Sign in to a few applications the old way first. The simulator below is the argument; the three cards under it are the verdict.

Password fatigue0%
0 logins0 resets

Sign in to a few apps — watch the mood drop.

Stolen passwords

One reused password reaches many apps

People reuse, and attackers count on it. A credential leaked from somewhere else becomes a sign-in attempt everywhere, and every extra password is one more that can be phished, reused or bought.

Offboarding

Leavers keep accounts nobody remembered

Every application has its own account to close, and offboarding becomes a checklist of consoles someone has to remember exists. One missed console is a live login for someone who has already left.

Visibility

No single record of who opened what

Without one sign-in point, “which applications did this person use last quarter?” means pulling logs out of every application separately — and it is a question that does eventually get asked.

What is SSO?

Single sign-on

One login session, honoured by many applications.

Single sign-on (SSO) is an authentication method that lets a user sign in once to a trusted identity provider and then open many applications without signing in again. Each application trusts a signed message from the identity provider — usually a SAML assertion or an OpenID Connect token — instead of keeping its own password for that user.

  • The user opens an appSalesforce, say. The application does not show a password box; it sends the user to the identity provider and waits to hear back.
  • The identity provider signs them inOne sign-in, carrying everything you require of it: the password, the second factor, and the check on the device it is being typed on.
  • It sends the app a signed messageWho the user is and which groups they belong to, signed so the application can verify it came from the provider and was not altered on the way.
  • SSO vs MFA: the most-asked questionSSO decides how often people sign in: once. MFA decides how strongly they prove who they are at that one sign-in. They are not alternatives — together they replace many weak logins with a single strong one.
Book a demoIdentity & Access
one user, one browser1login onceInstaSafe identity providerAUTHENTICATEuser ID••••••••SECOND FACTOR2one signed assertionHR portalSales appFinanceDev consoleFile shareevery app, one credential
800+applications already set up
3SSO protocols — SAML, OAuth, OIDC
202event types in the sign-in log
How it flows

From your directory to every app — in one token.

1 login → your whole app estate
Your directoryInstaSafe decidesYour apps
Active Directory
Google Workspace
Okta / your IdP
SaaS apps
Internal apps
Legacy apps
Authenticate
Issue SSO token
Apply policy
SAML assertion
NameID: you@company.com
AuthnContext: MFA
Session token
device: trusted · mfa: passed
ttl: 8h
Access decision
grant: your app estate
revoke: one click
Your directory
  • Active Directory
  • Google Workspace
  • Okta / your IdP
InstaSafe decides
  1. AuthenticateNameID: you@company.com
  2. Issue SSO tokendevice: trusted · mfa: passed
  3. Apply policygrant: your app estate
Your apps
  • SaaS apps
  • Internal apps
  • Legacy apps
Benefits

What changes with single sign-on.

Dozens of logins become one, and that one is protected properly.

Security

Shrink the password problem to one

Protect a single sign-in with MFA and a device check instead of dozens of separate passwords you cannot see. Password reuse stops mattering when there is only one password left to reuse.

Lifecycle

Onboard and offboard by group

Add a joiner to a group and the applications they are entitled to appear. Disable a leaver once and they cannot sign in to any of them.

Audit

Answer access questions with a report

Every application sign-in is one line in one log, so “who opened what, when, and from where” is an export rather than an investigation.

Use cases

Where InstaSafe SSO fits.

The four we are asked about most, from keeping the identity provider you already pay for to the leaver who still has a login somewhere.

Keep your identity provider

SSO behind Microsoft Entra ID, Okta or Google

Your identity provider carries on signing users in. InstaSafe integrates with it and onboards your users from there, then adds the device check and the Zero Trust access decision before any application opens. Nobody migrates, and no app integration is rebuilt.

If you have no identity provider, InstaSafe can be one. The same page covers both: InstaSafe as the provider, or InstaSafe as a service provider behind yours.

Modes
Identity provider, or service provider behind yours
Integrates with
Entra ID · Okta · Google Workspace · ADFS and other SAML providers
Adds
Device check · Zero Trust access decision
Identity provider SSO vs service provider SSO
Private apps

SSO for internal apps that are not on the internet

Internal web apps, on-premises systems and admin consoles sit behind InstaSafe Zero Trust access, so they have no public address to attack. The ones that speak SAML 2.0 or OpenID Connect get true single sign-on through the gateway: the user is already signed in, and the application is handed a signed assertion rather than a login page.

Older systems that speak neither get secure access rather than SSO — they are reachable through the same portal and the same policy, and they still ask for their own login. We say which is which rather than letting the word cover both.

Exposure
No inbound connections, no public address
Single sign-on
Apps that speak SAML 2.0 or OpenID Connect
Path
Through InstaSafe Zero Trust access only
Legacy application access
Desktop and network gear

One identity at the Windows desktop and the router console

On domain-joined Windows devices the morning's domain sign-in carries into the InstaSafe portal over Kerberos, so the day starts with no second prompt. Remote laptops get there the same way, because Always-On brings the tunnel up before anyone signs in. macOS and Entra-joined devices are supported too.

Routers, switches and firewalls cannot do single sign-on at all. They can check administrators against InstaSafe over RADIUS or TACACS+, with the same account, the same groups and the same MFA — which is the useful half of the claim, stated accurately.

Desktop SSO
Kerberos on domain-joined Windows; macOS and Entra-joined too
Remote users
Always-On brings the tunnel up before sign-in
Network devices
RADIUS · TACACS+, same account and MFA
How Always-On connectivity works
Joiners and leavers

Remove a leaver's access in one action

Add a joiner to a group in the directory you already maintain and their applications appear in the portal. Disable a leaver once and they can no longer sign in to any connected application.

Private applications behind InstaSafe go further than a standard SSO integration can: the connection is cut immediately, so a session already open on the far side of the gateway stops there rather than running on until a token expires.

Joiner
Add to a group in your directory
Leaver
Disable once; sign-in refused everywhere
Open sessions
Connections to private apps cut immediately
What is user provisioning and deprovisioning?
Capabilities

What InstaSafe SSO includes.

One login is the surface. Underneath it are the protocols your estate already speaks, the checks that login carries, and the record it leaves behind.

Three of these are single sign-on — SAML 2.0, OpenID Connect and Kerberos, where the application does not ask again. The rest carry the same identity, groups and MFA to the places that cannot do SSO at all.

8 protocols · one login
Web SSO

SAML 2.0

The assertion most business SaaS speaks. InstaSafe runs it in both directions — as your identity provider, or as a service provider federating to the one you already have.

IdP and SP initiated
Delegated access

OAuth 2.0

Authorises an application to act with a scoped token instead of handing it a password. The scope is the point: an integration gets what it needs and nothing adjacent.

Scoped tokens
Identity layer

OpenID Connect

OAuth with an identity claim on top, which is what modern applications actually ask for. Same single login, expressed in the format the newer half of your estate expects.

ID tokens on OAuth
Network access

RADIUS

The protocol your switches, wireless controllers and older VPN concentrators already talk. It means the network gear can ask the same identity a browser does.

Network device auth
Device administration

TACACS+

Separates authentication from authorisation and accounting, which is why network teams keep it for administrative logins to routers and firewalls.

Per-command control
Desktop SSO

Kerberos

The Windows domain login your people already completed this morning. Desktop SSO means that ticket carries into the portal — no second prompt at the start of the day.

Domain ticket reuse
Phishing-resistant

FIDO2 / WebAuthn

Hardware keys and platform biometrics, bound to the origin. A credential that cannot be replayed on a lookalike domain, because the browser refuses to offer it there.

Hardware-backed factor
Directory

LDAP

Reads the groups you already maintain in Active Directory or an LDAP server, so entitlement stays where your joiners-movers-leavers process already lives.

Group source of truth

MFA and a device check on the one sign-in.

Choose the factors each group must use — authenticator codes for plant staff, security keys for administrators — and optionally require an approved device as well. The factor is set on the group, so a new application never needs its own MFA setup.

MFA at the door,
not a second door

The single login carries the strong factors — 6 methods, and which ones are required is decided by the group.

app.acme.in/sign-in
Sign in••••••••••Sign inGroup: Finance · auth profileTOTPPushBiometricSecurity keySMS OTPEmail OTPnot required for this group
Signed in — one screen, two factors

The password was right.
The laptop was not.

Optionally require an approved device even with perfect credentials.

app.acme.in/sign-in
Sign in••••••••••credentials validSign inMacBook-Air-7F2Anot boundBound devices for this user (2)DESKTOP-4471LAPTOP-9930

One revoke,
and the connection drops

One action refuses the leaver a sign-in everywhere, and cuts the live connection to every private app behind the gateway.

admin.acme.in/people
Anita R.FinanceActiveRevokedCRMPayrollWikiRepos210live sessionsRevoke access13:42:07 · access removed from 4 applications, 2 sessions closed
Which applications

If it speaks SAML, it is already on the list.

The logos moving alongside are the ones we are asked about most, not the limit of what we support. Support is a protocol question rather than a catalogue question: anything that speaks SAML 2.0 or OpenID Connect can sit behind this login, and more than 800 applications have already been set up this way.

The ones with their own integration page are simply the ones where setup has a wrinkle worth writing down — a non-standard assertion, a desktop client, a legacy console that never learned SAML at all.

  • 800+ applications already set up
  • Any SAML 2.0 or OpenID Connect app works
  • 1 sign-in in front of every one
Microsoft 365Productivity & Collaboration
Microsoft TeamsProductivity & Collaboration
DropboxProductivity & Collaboration
SalesforceCRM & Sales
PipedriveCRM & Sales
ConfluenceITSM & Support
WorkdayHR & Identity
BambooHRHR & Identity
GitLabDeveloper & DevOps
Docker HubDeveloper & DevOps
Google CloudCloud Platforms
FigmaDesign & Productivity
SAPBusiness Applications
DocuSignBusiness Applications
Google WorkspaceProductivity & Collaboration
ZoomProductivity & Collaboration
BoxProductivity & Collaboration
HubSpotCRM & Sales
ServiceNowITSM & Support
ZendeskITSM & Support
SAP SuccessFactorsHR & Identity
Oracle HCM CloudHR & Identity
BitbucketDeveloper & DevOps
Amazon Web ServicesCloud Platforms
VMwareCloud Platforms
CanvaDesign & Productivity
OracleBusiness Applications
Monday.comBusiness Applications
SlackProductivity & Collaboration
Cisco WebexProductivity & Collaboration
NotionProductivity & Collaboration
Zoho CRMCRM & Sales
JiraITSM & Support
FreshdeskITSM & Support
DarwinboxHR & Identity
GitHubDeveloper & DevOps
JenkinsDeveloper & DevOps
Microsoft AzureCloud Platforms
AdobeDesign & Productivity
MiroDesign & Productivity
QuickBooksBusiness Applications
The record

A record of every sign-in.

Each sign-in is logged with the user, time, application, device, location, result, and the policy rule that allowed or refused it. Report on it in the console, or send it to your SIEM in seven formats — among them CEF, LEEF and JSON.

202 event types

Aggregate access data.

Top apps, devices, users and locations rolled up from every access event — and exportable to your SIEM.

The portal

One portal for every app a user is allowed.

After one sign-in, people see the applications their role gives them and open any of them with a click. Applications they are not allowed do not appear. Flip the switch to watch the same morning without it: three apps, three sign-ins, and a reset link somewhere in every one of them.

InstaSafe
Alen JosephSigned in once · 08:59
SalesforceMicrosoft 365GitLabSlackZoomWorkdayNotionDropbox
One login, every appWork emailalen.joseph@acme.inContinueMFA + device posture
Salesforceopened without a password
Microsoft 365opened without a password
GitLabopened without a password

With InstaSafe: one login at 08:59. Everything after it is work, not authentication.

Sign-in simulator

Run the same morning twice.

Six applications with six passwords and a reset somewhere in the middle, then the same six after one InstaSafe sign-in. A simulation with example timings — no account needed, and nothing here talks to a live directory.

Without SSO01:47
vs
With InstaSafe00:09

Example timings

Platform

How SSO fits the rest of the policy.

Single sign-on answers who the user is. The rest of InstaSafe decides what that user may reach, from which device, over which path — in the same access policy, not a second product.

BEFORE SSOMany logins. Many passwords.••••••••••••••••••••••••••••••••••••WITH SSOOne login. All access.INSTASAFE SSOSign in to continueuser@yourcompany.com••••••••Sign inorSign in with MFAVerified. Secured. Seamless.AFTER SSOOne session. Every app.AWS ConsoleSlackSAPSalesforceJenkinsOracleSESSION LOG09:10:21SUCCESS09:12:44SUCCESS09:18:07SUCCESS
SSO outcomes

One door.Everythingbehind it.

Fifty logins collapse into one, and that one is the login you can afford to defend properly.

The password problem shrinks to one

Defend one login properly instead of fifty badly. Reuse stops mattering when there is nothing left to reuse it across.

Joiner-leaver in minutes

Access follows group membership. Disabling the user is offboarding — refused everywhere at once, and cut immediately on the private apps behind the gateway.

Access becomes auditable

Every application login is one line in one log, so the audit question is a report rather than an investigation.

Quick scan

Single sign-on, as a checklist.

Tick what your evaluation actually needs and copy the shortlist straight into your ticket. Filtering hides rows; it never clears a tick.

15 specs · none selected

SSO FAQ

Single sign-on, answered.

Tap a question, or open them all and read straight through.

Talk to us

//Ready when you are//

Give your team one sign-in.

Single sign-on with MFA and device checks built into the login itself. See it running on your own applications in 30 minutes.

Talk to sales
Regulated, air-gapped, or on-premises? See deployment options