SSO, SCIM and two-step sign-in for city staff: a practical guide
Single sign-on, automatic account removal and two-step sign-in, explained for city IT. What each one does, how they fit together, and what to require from any system that touches resident data.
Every new system a city buys comes with its own sign-in. Each one is another password for staff to remember, and another account for IT to remember to remove when someone leaves. The usual answer is three features that work together: single sign-on, SCIM and two-step sign-in.
This guide explains each in plain terms, then lists what to require from vendors.
Single sign-on (SAML)
Single sign-on lets staff sign in with the account they already use for email and their computer. The system you bought trusts your identity provider, such as Microsoft Entra ID, Okta or ADFS, to confirm who someone is.
SAML is the most common standard for this in government. In practice it works like this:
- A staff member opens the app and chooses "Sign in with your organization".
- The app sends them to your identity provider.
- They sign in there, with your usual password and two-step rules.
- The identity provider sends them back with a signed message saying who they are.
What it gets you
- One password, managed by your policies.
- Your two-step and conditional access rules apply automatically.
- Disabling someone's main account blocks the app too.
What to watch for
- Local passwords still working. If the app keeps its own passwords alongside SSO, a departed employee may still get in. Ask whether you can require SSO only.
- Who gets in. Some apps create an account for anyone your identity provider sends. Decide whether that is what you want, and which role new people get.
SCIM: keeping the list of people in step
SSO controls sign-in. It doesn't tell the app that someone left. Their account, role and API tokens may still sit there, unused but valid.
SCIM is a standard way for your identity provider to tell an app about changes to people: someone joined, changed name or left. When a person is removed in the directory, SCIM removes or disables them in the app at once.
For systems that move resident data, that matters. Accounts left behind after someone leaves are a common finding in security reviews.
Two-step sign-in
Two-step sign-in (often called MFA) asks for something beyond a password, usually a code from an authenticator app. Even if a password is guessed or phished, the account stays closed.
Requirements worth asking for:
- It can be required, for everyone in your agency, not just offered.
- Authenticator apps are supported, not only text messages.
- Recovery codes exist, so a lost phone doesn't mean a support ticket at midnight.
- An admin can reset it for a person, and the reset is logged.
If staff sign in through SSO, your identity provider usually handles the second step. Two-step sign-in inside the app matters for accounts that don't use SSO.
How they fit together
| Feature | Answers the question |
|---|---|
| SSO | Is this really our employee? |
| Two-step sign-in | Is it really them, not someone with their password? |
| SCIM | Do they still work here? |
| Roles | What are they allowed to do? |
| Network allow-lists | Are they signing in from somewhere we expect? |
No single feature covers everything. Together, they turn "we think access is under control" into something you can show an auditor.
Don't forget the non-human accounts
People are only part of the picture. Integration platforms also use:
- API tokens for scripts and other systems.
- Tokens for AI assistants that read or draft flows.
- Service accounts in the systems being connected.
Ask whether tokens can expire, whether they are limited to the person's own role, whether they can be limited to your networks, and whether each one shows in an activity log.
A checklist for any system touching resident data
- SAML single sign-on with your identity provider.
- An option to require SSO and disable local passwords.
- SCIM, so removed people lose access at once.
- Two-step sign-in that can be required for everyone.
- Strong password rules for any local accounts.
- Roles, including a read-only role.
- Network allow-lists for sign-in and tokens.
- An activity log of sign-ins and changes, which you can export.
Rolling it out without drama
- Start with IT and a pilot department.
- Set up SCIM before SSO goes live, so the people list is right from day one.
- Announce the two-step requirement a week ahead, with a short how-to.
- Keep one break-glass admin account, stored safely, in case the identity provider is down.
In SentraBridge
Each SentraBridge workspace can use SAML single sign-on, with SCIM 2.0 adding and removing people automatically. Workspaces can require two-step sign-in, allow SAML only, and limit sign-in, API tokens and AI assistants to your networks. Read more on the security page and under multi-client workspaces.