SSO removes a password per service and concentrates risk in one place. That trade is usually worth making — provided the identity provider itself is protected better than the accounts behind it.
Single sign-on lets people authenticate once with an identity provider and reach every connected application without logging in again. For the person it removes a dozen passwords; for the business it puts joining, leaving and access changes in one place instead of a dozen.
It also concentrates risk deliberately. One account now opens everything, which is an improvement if that account is protected with phishing-resistant authentication and a disaster if it is protected with a reused password. The trade is generally worth making, and only when you make the second half of it too.
SSO does not remove the need to review access. It makes access easier to grant and therefore easier to over-grant, and group membership tends to accumulate. The periodic review described in access control policy matters more after adopting single sign-on, not less — the mechanism that made joining easy made leaving-a-team invisible.
SAML and OIDC are the two protocols you will meet; OIDC is the more modern and is what most newer products implement. SCIM is a separate standard for provisioning — creating and disabling accounts automatically — and is what actually delivers the offboarding benefit above. A product supporting SSO but not SCIM still requires somebody to remove the account by hand, which is worth knowing before assuming the problem is solved. Social login is not the same thing: signing in with a consumer account is convenient and does not give a business control over the identity.
Below roughly ten people, a shared password manager with unique credentials and two-factor authentication everywhere achieves most of the security benefit at a fraction of the cost and complexity. SSO earns its place when the number of people times the number of applications becomes unmanageable by hand, or when a customer or auditor requires it. It is worth being honest that the second reason is often the real one.
Ettex Teams holds who is on the team and what they can reach, and account-level sign-in supports passkeys — the phishing-resistant option that any SSO deployment should be paired with. The surrounding policy documents are access control policy and information security policy.
Being direct about the boundary: we do not provide an identity provider, and enterprise SSO federation is not something to assume is present — check the current plan details rather than inferring from this article. What is described here is how to evaluate the decision, not a product claim.
Authenticating once with an identity provider and reaching every connected application without logging in again, with access managed centrally.
Usually yes, because it removes reused passwords and centralises policy — but only if the identity provider itself uses phishing-resistant authentication, since one account now opens everything.
SSO handles authentication; SCIM handles provisioning — creating and disabling accounts. Without SCIM, offboarding may still require removing accounts by hand.
Below about ten people, a shared password manager plus two-factor authentication delivers most of the benefit. SSO earns its cost as people times applications grows, or when a customer or auditor requires it.
Turning on two-factor authentication is the single highest-value security change most small teams can make. Which second factor you pick decides whether it stops the attack that actually happens.
Forced ninety-day changes, three special characters, no repeats — most password rules were written from intuition and make passwords weaker. The current guidance says something close to the opposite.
Phishing awareness is sold as training and works as design. The teams that get hit least are not the best educated — they are the ones where reporting is easy and the dangerous actions have a second check.