Your team already has a company login. With single sign-on (SSO), they use it for NextUp Walk-in too: type a work email, sign in where you always sign in, and land in the business. You prove your domain, test it, and turn it on. With user sync, when someone leaves, their access ends once your provider sends the change.
Work emaildana@harborauto.exampleContinueYour company will ask you to sign in
Example: Dana, at a made-up company with several shops, types her work email. The company login does the rest.
15
Checks and protections
13
Controls, each with the threat it answers
7
Standards and algorithms implemented
5
Areas covered, from sign-in to audit
How Single Sign-On (SSO) Works
Three steps, and the second one is the login your people already know.
1
Type your work email
On the NextUp sign-in page, choose “Sign in with your company” and type your work address. NextUp looks at the part after the @.
2
Sign in at your company
You are sent to your own company’s login, the one you use for everything else, with whatever checks your company has set there.
3
Land in NextUp
Your company confirms who you are and sends you back. You are signed in, with no separate NextUp password to remember.
What Single Sign-On Covers
Every capability in one table, with its status and the code behind it. Filter it, search it, sort it. Every row names the code behind it.
50capabilities
What is built today
50 capabilities, built into the product50 capabilities built into the product
5 areas, from how people sign in to how it is run day to day. Pick an area below to see exactly what is in it, or a capability to jump to its row.
50 included
Where Each Part Has Run
Built is not the same as proven on a real provider. This is what has run on a real identity system, and what has only run against a test server and fakes.
1 Run on real providers
7 Tested against Keycloak and fakes
2 Not yet run
OpenID Connect sign-in
Run on real providers
Exercised by us on a real Okta org and a real Microsoft Entra ID tenant, in a test environment, not production: the owner’s test sign-in, turning it on, a real sign-in, a second sign-in, the Required refusal, and the wording for a wrong secret and a wrong issuer.
Okta, Microsoft Entra IDNov 3, 2026
SAML 2.0 sign-in
Tested against Keycloak and fakes
Run against Keycloak and fake providers. Not run on Okta, Microsoft Entra ID or Google Workspace.
Encrypted SAML assertions and signed requests
Tested against Keycloak and fakes
Run against Keycloak and fake providers. Not run on a real provider.
Provider-started SAML sign-in
Tested against Keycloak and fakes
Run against Keycloak and fake providers. Not run on a real provider.
App-launcher tiles
Not yet run
The sign-in link a tile opens is tested; a vendor’s own tile (Okta, Microsoft Entra ID, Google Workspace) has not been run.
Single logout
Tested against Keycloak and fakes
OpenID Connect back-channel logout ran against Keycloak. SAML logout ran against fakes that sign the message with the SAML library. Not run on a real provider.
SCIM users and groups
Tested against Keycloak and fakes
Fakes only: the payloads follow Microsoft Entra ID’s and Okta’s documentation. Not run on a real tenant.
Roles from groups at sign-in
Tested against Keycloak and fakes
The shapes of the group claims ran against Keycloak. Not run with a real tenant’s groups.
Multi-factor sign-in labels
Tested against Keycloak and fakes
The OpenID Connect acr label ran against Keycloak; amr labels and SAML contexts ran against fakes. Not run on a real provider.
Sign-in log sent to your collector (syslog over TLS)
Not yet run
Run against a real rsyslog collector in a container and a fake one, with a private CA. Not run against a SIEM product.
Real-provider runs are planned for the others; ask us which providers we have run for you.
Showing 50 of 50
Single sign-on capabilities, their status, and the code behind each
Detail
Code
Sign-in standards
OpenID Connect with PKCE
Sign-in standards
included
Authorization code flow with PKCE (S256). Signature, issuer, audience, expiry and nonce are checked.
api/Sso/SsoOidc.cs
SAML 2.0
Sign-in standards
included
Sign-in that starts at NextUp. The response’s signature, audience, destination, time window and request id are checked.
api/Sso/SsoSaml.cs
SAML metadata import
Sign-in standards
included
Give an https address or paste the XML, and the sign-in URL and certificate are filled in.
api/Sso/SsoSamlMetadata.cs
Several signing certificates for a rollover
Sign-in standards
included
Up to four SAML certificates can be held at once, so the old and the new both work.
api/Sso/SsoSaml.cs
Sign-in from an app-launcher tile or bookmark
Sign-in standards
included
A tile that opens NextUp’s sign-in link starts a normal sign-in and lands the person signed in.
api/Sso/SsoEndpoints.cs
Company sign-in from the Android app’s sign-in sheet
Sign-in standards
included
The app’s sign-in sheet hands off to the same company sign-in and returns with a one-time code. Checked on the server side only.
api/Sso/SsoSessions.cs
Replay protection
Sign-in standards
included
Each sign-in is tied to the browser that started it and works once. A repeated state or SAML response is refused.
https only, public addresses only, no hops to another host, and tokens and secrets are not written to logs on purpose.
api/Sso/SsoNet.cs
IdP-initiated sign-in (opt-in)
Sign-in standards
included
Off by default, and with it off the answer is ignored and nothing is recorded. When the owner turns it on for a SAML sign-in, the provider’s own tile can sign in people who already belong to the business: the answer must be signed by your certificate, under five minutes old, for NextUp, and works once. If the browser already has a NextUp session open, the person is asked “Continue as …?” and must click Continue before it is replaced. It never makes an account or skips the emailed link.
Single sign-out, OpenID Connect (back-channel logout)
Sign-in standards
included
When your provider signs someone out, it tells NextUp and that person’s sessions through this connection end. It needs a provider that sends back-channel logout.
Single sign-out, SAML (the provider’s logout request)
Sign-in standards
included
A logout request your provider signs ends that person’s sessions through this connection, including sessions finished at the authenticator-code step and re-issued ones. A request that is unsigned, older than ten minutes, or not addressed to NextUp’s sign-out address is refused, and the provider’s sign-out address must be on the same site as its sign-in address. NextUp does not start a SAML logout itself.
Signing out of NextUp also signs out of the company login (OpenID Connect)
Sign-in standards
included
Optional, off by default. After NextUp signs the person out, their browser goes to your provider’s sign-out page. Some providers ask them to confirm. NextUp keeps no ID token, so for some providers this does not end the provider’s own session.
Optional. The owner makes a certificate of NextUp’s own for the sign-in and gives it to the provider; NextUp opens AES-encrypted assertions with RSA-OAEP and refuses the older RSA 1.5.
api/Sso/SsoSaml.csapi/Sso/SsoSamlKeys.cs
Signed SAML requests
Sign-in standards
included
Optional. NextUp signs the sign-in requests it sends with the sign-in’s own certificate (RSA with SHA-256), for a provider that checks them. Two certificates can overlap while a provider switches over.
api/Sso/SsoSaml.csapi/Sso/SsoSettingsService.cs
Several identity providers per business
Sign-in standards
included
Up to five company logins per business, for a merger, a contractor or a subsidiary. Each has its own type (OpenID Connect or SAML), email domains, roles from groups, SCIM token and Required switch.
Standard SCIM 2.0 requests. A changed name, or a work email on a verified domain, follows to NextUp. SCIM reaches only people whose address is on one of the connection’s verified domains, takes the filter operators eq, ne, co, sw, ew and pr joined by and, and caps how many new accounts one connection can make an hour.
api/Sso/ScimService.csapi/Sso/ScimEndpoints.cs
SCIM turn-off and delete
Provisioning
included
Off the team, sessions ended, security stamp changed. The account and its records are kept. An owner is never touched.
api/Sso/ScimService.cs
Turn back on, keeping the role
Provisioning
included
Someone who returns comes back with the role they left with, not the default.
api/Sso/ScimService.cs
Account made at first sign-in
Provisioning
included
A new address on a verified domain gets an account at once, as staff or manager. Never as an owner.
Groups your identity system pushes are kept per connection, up to 500 groups of 10,000 people. Their names also match the Roles from groups lists, and a role changes the moment a group does. A group never removes anyone.
A TXT record at _nextup-verify.<domain>. Public mail domains can’t be used, and a domain belongs to one business.
api/Sso/SsoDomainRules.cs
Emailed confirmation for existing accounts
Access control
included
An existing account not yet on the team, the owner’s own account and a new provider account for an address that already has one are never signed in on the provider’s word alone. A link to its own mailbox finishes it.
api/Sso/SsoConfirmationService.cs
Required mode
Access control
included
Passwords, codes, Google, Apple, Facebook or Microsoft sign-in and passkeys are refused for the business’s own team on the proved domains. Someone who is not on the team keeps an ordinary sign-in.
api/Sso/SsoRequiredMode.cs
Owner break-glass in Required mode
Access control
included
The business’s owner is exempt, and Required can be turned on only after the owner has signed in through the provider.
A custom role’s group, else a manager group, else a staff group, else the default. Exact, case-sensitive match, on the groups in the sign-in and the SCIM groups together. An owner is never changed.
api/Sso/SsoGroups.cs
NextUp staff accounts excluded
Access control
included
A platform admin account can never sign in through a company login, and can’t be locked out by one.
api/Sso/SsoSignInService.cs
Locked accounts refused
Access control
included
An account NextUp has locked is refused before anything is added or linked.
api/Sso/SsoSignInService.cs
Settings need a recent sign-in
Access control
included
The business’s owner, or a manager the owner allowed, after a sign-in from the last 10 minutes. A NextUp support session and an API key are refused.
The owner names a set of the four manager permissions (refunds, team pay, change prices, manage company sign-in) and gives it to managers by hand or from a company sign-in group. Owner, manager, team member and the read-only accountant stay the levels, and a role adds no permission beyond those four.
Off by default. When on, a sign-in the provider does not report as multi-factor is refused. Any one of the provider’s own second-method labels counts (a one-time code, a security key or a fingerprint, for example), so NextUp cannot tell how strong the method was or see how anyone signed in.
The owner chooses the whole team on the verified domains, or only people in listed groups. NextUp checks before anyone signs in, so it uses the groups from their last sign-in and from SCIM Groups, which are only as fresh as those: turn on SCIM Groups to keep them exact. A person it knows no groups for is held to Required.
Up to five people on the team (never a NextUp platform admin) who may still use a password and NextUp’s own methods while Required is on. The owner adds and removes them, the card shows who added each and when, and every change is in the activity log.
The owner can allow chosen managers to set up connections as drafts, domains, tests and group mapping, and to rotate a client secret for the same provider, signed in within the last 10 minutes. A manager cannot change who the identity provider is (its issuer, client ID, entity ID, sign-in address, certificates or claim names), make a SCIM token, turn on a connection the owner has not tested, make new people managers (the default role or the manager groups), turn on the launcher sign-in or signed requests, change Required, the emergency sign-ins, our certificates or the session and multi-factor settings, remove a sign-in, or allow others: those stay with the owner. Every change names the person who made it.
The owner can ask people to sign in through the company again every 1 hour to 30 days, counted from the sign-in. The owner can always sign in another way.
Every change, domain change, test, SCIM token, person added or removed, company sign-in, and every sign-in that did not finish once NextUp knows who it was, with the reason. A refusal before that goes to the server log only.
The business’s activity log can be downloaded as a spreadsheet.
api/Accounts/ActivityExport.cs
Company sign-in log download
Audit and monitoring
included
The owner, or a manager the owner allowed, downloads the company sign-in log as CSV or JSON for up to 366 days and up to 100,000 events per download: time, action, person, connection, method, outcome and reason. No IP addresses, tokens or secrets.
A log collector pulls the same events as newline-delimited JSON, in order, from a cursor, using the owner’s API key. No IP addresses, tokens or secrets.
A missing record is looked at again a day later. A second miss stops the domain and emails the owner.
api/Sso/SsoDomainRecheck.cs
Send the sign-in log to your own collector (syslog over TLS)
Audit and monitoring
included
The owner names up to three collectors. Each company sign-in event is sent as a syslog message (RFC 5424) over TLS only, in order, at least once, with an event ID to drop repeats, on a short list of ports, to a public address; the collector’s certificate is checked, or a CA the owner pinned. No IP addresses, tokens or secrets. Events older than 7 days are not sent late.
Goes to the provider and back, signs nobody in, changes nothing, and shows what came back, including the groups.
api/Sso/SsoTestSignIn.cs
Certificate expiry badges
Operations
included
Calm until 30 days are left, then a warning, then Expired, on the owner’s settings screen.
web/src/app/pages/dashboard/sso-card.ts
Certificate and secret expiry reminders
Operations
included
The owner is emailed 30, 14, 7 and 1 days before a SAML certificate expires, and once when it has. For an OpenID client secret the owner enters its date once. The card keeps a warning up at 30 days or fewer.
NextUp support can see, read-only, how a company login is set up and what it last did, and why a given person can’t sign in. Every view goes in NextUp’s own admin log. No secrets are shown.
“Included” means built and working today for a business that has single sign-on turned on. “On request” means not a setting; tell us if you need it. “Not built” is the plain status of what the product does not do.
15 Checks and Protections Around Company Sign-In
Each of these runs where it applies, and a company sign-in is accepted only when the ones that apply to it pass. Hover or focus one to see what it does and what it refuses.
If Your Identity Provider Were Compromised
Single sign-on makes your provider a door into NextUp, so here is how far that door goes: what it can reach, and what stays out of reach whatever it says.
Two Standards, Most Identity Systems
Single sign-on is standards-based, so it follows the identity system you already run instead of asking you to switch.
OpenID Connect
The modern, simple standard. Your IT admin creates an app in the identity system and gives NextUp an issuer, a client ID and a client secret.
Authorization code flow with PKCE
The sign-in token’s signature, issuer, audience, expiry and nonce are checked
The client secret is stored encrypted and never shown again
SAML 2.0
The long-standing standard behind many company logins. Your IT admin pastes NextUp’s values into the app and gives NextUp the sign-in URL and signing certificate.
The response’s signature is checked against your certificate (up to four can be held, for a rollover)
Audience, destination, time window and the request it answers are checked
Each response works once; a replayed one is refused
Setup Steps On Request For
Microsoft Entra IDOpenID Connect or SAML 2.0Pinned to your own tenant: a sign-in from any other tenant is refused.
OktaOpenID Connect or SAML 2.0Use your org’s authorization server (the bare Okta address) unless you have API Access Management.
Google WorkspaceSAML 2.0A custom SAML app in the Google Admin console; our steps are written from Google’s documentation.
Cisco DuoSAML 2.0Through Duo Single Sign-On; our steps are written from Duo’s documentation.
Another identity system that speaks OpenID Connect or SAML 2.0 asks for the same kinds of values: an issuer or sign-in URL, a client or certificate, and an email address for each person.
Standards We Implement
Standards implemented and what each is used for
Standard
Version or scope
Used for
OpenID Connect
Authorization code flow
Sign-in through the company’s identity system, with discovery from the issuer address.
PKCE
S256
Protects the OpenID code exchange; a provider without S256 is refused.
OAuth issuer identification
RFC 9207
The callback’s issuer must be the one the owner configured.
JSON Web Signature
RS, PS and ES 256, 384 and 512
Algorithms accepted for an OpenID token’s signature.
SAML
2.0
Request by HTTP-Redirect, response by HTTP-POST, signed responses checked against saved certificates.
XML Signature
RSA and ECDSA with SHA-256, 384 or 512
Signature and digest methods accepted for a SAML response.
SCIM
2.0 (RFC 7644), users and groups
Create, update, turn off and delete people; create, rename, change the members of and delete groups. User filters: eq, ne, co, sw, ew and pr joined by and.
These are standards NextUp implements. No certification or attestation is claimed for any of them.
People Added And Removed Automatically
SCIM 2.0, for users and groups. Roles follow your groups: the ones in a person’s sign-in and the ones your identity system pushes through SCIM, applied the moment a group changes. You make a SCIM token on the settings screen, and your IT admin pastes it into the identity system with NextUp’s SCIM address.
Create
A new person in your identity system gets a NextUp account on your team, as staff or manager, whichever you chose. Never as an owner.
Update
A changed name, or a changed work email on a verified domain, follows to NextUp, so the two don’t drift apart. The person keeps the same NextUp account, role and history, and signs in again after an email change.
Turn off
Turn someone off, or delete them, and they come off the team and are signed out of NextUp everywhere, including any other business they use. Their account and its records are kept.
Joiner, Mover, Leaver
You Decide Who Gets In
Nobody can sign in for your company until you have proved it is yours.
Prove the Domain
Name_nextup-verify.harborauto.exampleTypeTXTValuea long random value NextUp shows youharborauto.example is verified
Example. Your IT team adds the record at the company’s DNS host, and the owner presses Verify on the settings screen.
Your domain, proved by a DNS record
Before anyone can sign in through your company, you add one TXT record named _nextup-verify at your domain to prove it is yours. Public mail domains such as gmail.com can’t be used, a domain belongs to one business only, and nobody can prove a domain they don’t control, so nobody can sign people in for addresses that aren’t theirs. Keep the record in place: NextUp checks it weekly, and if it is missing twice, a day apart, the domain stops working and your owner is emailed.
Required mode: company login only
Turn it on and, for the people on your team whose address is on your proved domains, passwords, emailed or texted codes, Google, Apple, Facebook or Microsoft sign-in and passkeys are refused. People on your team who are signed in another way are signed out once, and sign back in through the company. Someone who is not on your team, such as a customer of another business who used a work address, keeps an ordinary sign-in. The business’s owner is exempt, so a broken company login does not lock the owner out. It can be turned on only after the owner has signed in through the provider. If the business drops below Pro, or we turn single sign-on off for it, Required stops applying and people sign in the usual ways.
Access ends when the company ends it
With user sync on, once your provider sends the change, turning someone off in your identity system takes them off the NextUp team, ends their sessions and changes their security stamp. It does not delete their account or its records, and it never touches an owner.
Every change and sign-in is on the record
The activity log gets an entry for every change to the connection or its domains, every test, every person added or taken off by sync, every new SCIM token and every company sign-in.
Walk Through The Domain Proof
Roles That Follow Your Groups
The owner lists the groups that mean manager and staff, and each sign-in sets the role from them. Try it: this runs the same rule the sign-in does.
One Settings Screen, for the Owner and Chosen Managers
Everything is on Owners & Managers in the dashboard: the choices, the values to copy for your IT admin, your domain, a test, and the switches.
Owners & ManagersSingle Sign-On
TypeOpenID ConnectSAML 2.0
Connection nameHarbor Auto Group
Domainsharborauto.exampleVerified
Test sign-inTest sign-inIt worked for dana@harborauto.example
Enabled
Required
User syncMake SCIM token
Example of the settings screen. The names are made up; your values come from your provider.
The owner, or a manager they allow
The settings are on Owners & Managers, under Sign-in security. The owner sets them up, or a manager the owner allowed does. Who the identity provider is, the SCIM token, Required, the emergency sign-ins, our certificates, session and multi-factor settings, removing a sign-in and who may manage stay with the owner, and so does anything that would make new people managers or turn on the launcher sign-in or signed requests. Any change needs a sign-in from the last 10 minutes.
Test before it’s on
A test sign-in goes to your provider and back, signs nobody in and changes nothing, then shows what came back. The Enabled switch is yours to flip once it works.
Switch it off any time
Turn Enabled off and everyone signs in the usual ways again. Nothing is deleted.
Setup For Your IT Admin
A short list of steps, with the exact values on the screen to copy. Ask and we send setup steps for Microsoft Entra ID, Okta, Google Workspace and Cisco Duo.
1
Owner picks the standard
In NextUp, the owner chooses OpenID Connect or SAML 2.0, gives the connection a name (your company’s, for example) and picks the role new people get.
2
IT adds one DNS record
NextUp shows a TXT record. IT adds it at the company’s DNS host, and the owner presses Verify.
3
IT creates the app
In Entra ID, Okta, Google Workspace, Duo or another provider, IT creates an app with the values NextUp shows, copy-ready on the screen, and assigns who may sign in.
4
Owner tests, then turns it on
The test sign-in must show an address on the verified domain. Then the owner switches it on, and people see “Sign in with your company”.
5
Optional: sync, groups, Required and a launcher tile
Add user sync with a SCIM token, list the groups that mean manager, staff or a custom role, point a tile or bookmark in your app launcher at the sign-in link on the screen, and turn on Required mode once everyone has signed in once.
Are You Ready To Set It Up?
How It Is Kept Safe
What single sign-on does to protect your sign-ins. The Security page covers the rest of NextUp Walk-in, including what we do not have.
Controls And The Threat Each Addresses
Security controls and the threat each addresses
Control
Threat it addresses
How
Single-use state tied to the browser
Someone finishing a sign-in that another person started
The state and a cookie must both come back, once.
Nonce and request id
A captured answer replayed or injected
The answer must match the request NextUp made, and works once.
Signature, issuer and audience
A forged answer, or one meant for another application
Checked against your provider’s keys or saved certificates.
Tenant pinning for Microsoft Entra ID
A sign-in from a different Microsoft tenant
Shared endpoints are refused and the tenant must match.
Domain proof by DNS
A company claiming addresses that aren’t theirs
A TXT record only the domain’s owner can add; public mail domains refused.
Weekly domain re-check
A lapsed or sold domain that keeps working
A second miss stops the domain and emails the owner.
Mailbox confirmation
A provider taking over an existing account
An existing account not yet on the team, the owner and a new provider account for a known address confirm by their own mailbox.
Role never owner
A group or default promoting someone to owner
New people are staff or manager; an owner’s role is never changed.
NextUp staff accounts excluded
Reaching NextUp’s own administration through a customer’s login
A platform admin account is refused, and can’t be forced into Required mode.
No durable credential from a company-only session
A compromised provider leaving a backdoor behind
Passkeys, authenticators and API keys need a NextUp proof first.
Careful fetching of provider addresses
Using the provider URL to probe a private network
https only, public addresses only, no cross-host redirects.
Encrypted client secret, hashed SCIM token
A leaked database exposing credentials
The secret is encrypted; only a hash of the token is kept.
Owner break-glass
A broken company login locking the business out
The owner is exempt from Required mode and can switch the connection off.
Security Questionnaire Answers
Where is our data stored?
NextUp Walk-in is for businesses in the United States, and its data is stored in the United States. A few service providers handle limited data elsewhere for one feature each; the privacy policy and the subprocessors page list them. Subprocessors
Are secrets encrypted at rest?
Yes. The OpenID client secret is encrypted and never shown again. A SCIM token is shown once and only a one-way hash is kept. Backups are encrypted.
What is logged?
Every change to the connection or its domains, every test, every person added or removed by sync, every new SCIM token, every company sign-in and every one that did not finish goes in the activity log. The owner can download the company sign-in log as CSV or JSON, and a log tool can pull it as a feed. A business can also have it sent to its own log collector over TLS as syslog. Tokens and secrets are never in the activity log, and the downloaded, pulled and sent company sign-in log also leaves out IP addresses (the activity log itself records the IP address of each request); a refused sign-in keeps only the provider’s error code, never words a caller wrote; the same refusal repeated is one row a minute.
What is the multi-factor stance?
A completed company sign-in counts as the second step, the way a passkey does. By default NextUp does not check that your provider asked for one, so require multi-factor sign-in in your provider’s policy. The owner can also turn on a check that refuses any sign-in the provider does not report as multi-factor; NextUp reads what the provider’s signed answer says and cannot see how anyone actually signed in. Anyone who signs in another way keeps NextUp’s own two-step sign-in, and a passkey, authenticator or API key can’t be added from a company-only session.
Which claim does NextUp trust for a person’s email address?
The provider’s email claim (for Microsoft Entra ID, its preferred username or user principal name when no email is sent), and only for an address on a domain the company proved. A new provider account for an address that already has one is not linked on that claim alone: the person confirms by an emailed link. A tenant administrator of your own identity provider is inside that trust.
How do single logout and client authentication work?
NextUp ends sessions when your provider sends a signed OpenID Connect back-channel logout or a signed SAML logout request; it never starts a SAML logout. Signing out of NextUp can also open the provider’s sign-out page (OpenID Connect, off by default); NextUp keeps no ID token, so it sends no ID token hint and for some providers that does not end the provider’s own session. OpenID Connect clients authenticate with a client secret; a private-key option is built when a customer asks for it. NextUp’s SAML metadata is not signed.
How does offboarding work?
With user sync on, turning someone off or deleting them takes them off the team, ends their sessions and changes their security stamp, once your provider sends the change. Their account and records are kept. Without user sync, an owner removes them from the team.
Can NextUp staff sign in through our login or change our settings?
No. A NextUp platform admin account can never sign in through a company login, and a NextUp support session is refused when it tries to change the settings.
Do you hold a security certification?
No. We hold no SOC 2, ISO 27001 or other security certification. The Security page lists what we do and what we don’t have. Security page
With And Without Company Sign-In
What changes for the people who run a business and the people who work in it.
Without and with company sign-in, by topic
Topic
Without
With company sign-in
Onboarding
Each person makes their own NextUp account and password.
A new person signs in with their work email, or with user sync is added to the team for them.
Offboarding
An owner removes the person on NextUp, separately from the company’s other accounts.
Turned off at your provider, they come off the team and their sessions end once the provider sends the change.
Passwords and resets
Another password to remember, and to reset.
No NextUp password to remember for the company login. Required mode refuses the other ways in.
Multi-factor policy
Each person sets up NextUp’s own two-step sign-in.
Your provider’s policy runs first, including its multi-factor rules.
Audit trail
Sign-ins and changes are recorded in NextUp only.
Company sign-ins, tests, additions and removals are in the activity log beside your provider’s own records.
Pro
On The Pro Plan And Up
Single sign-on is part of Pro and Restaurant, with no separate price. We turn it on for your business when you ask, then the owner sets it up. See what else is on each plan on the pricing page.
Which plans include single sign-on, and what does it cost?
Single sign-on is part of the Pro plan and up (Pro and Restaurant), with no separate price. It isn’t on the Free or Walk-in plans.
How do we get it?
Ask us to turn it on for your business through the contact form. Once it’s on, the business’s owner finds Single Sign-On on Owners & Managers and sets it up.
Which identity systems can we connect?
It is standards-based: OpenID Connect and SAML 2.0. We send setup steps for Microsoft Entra ID, Okta, Google Workspace and Cisco Duo when you ask, written from each vendor’s documentation. Another system that speaks either standard asks for the same kinds of values.
Do our people still need a NextUp password?
Not to sign in through your company. Until you turn on Required mode, people who already have a NextUp account can still use their usual way in. With Required mode on, the people on your team whose address is on your proved domains must use company sign-in, and the business’s owner stays exempt as a safety net. Turning Required on signs those people out once. It holds your own team only: someone who is not on it, such as a customer of another business who used a work address, keeps an ordinary sign-in.
What happens when someone leaves the company?
With user sync on, turning them off in your identity system takes them off the team and signs them out of NextUp everywhere, including any other business they use, once your provider sends the change. Their NextUp account and its records are kept. Without user sync, turning them off at your provider stops them signing in through your company login, and an owner removes them from the team on NextUp.
Can a stranger claim our email domain?
No. Your domain only works after a DNS record that only your IT team can add proves it is yours. A domain can belong to one business, public mail domains such as gmail.com can’t be used, and nobody can prove a domain they don’t control.
What if our identity provider is down or set up wrong?
The business’s owner is exempt from Required mode, so the owner can still sign in the usual way and switch the connection off. Nothing is deleted when you do. If the plan drops below Pro, or we turn single sign-on off for the business, Required stops applying and people sign in the usual ways.
Does it replace two-step sign-in?
A company sign-in counts as the second step, the way a passkey does. By default NextUp does not check that your provider asked for one, so require multi-factor sign-in in your provider’s policy. The owner can also turn on a check that refuses any sign-in the provider does not report as multi-factor. NextUp reads what the provider’s signed answer says and accepts the provider’s own labels for a second method (a one-time code, a security key or a fingerprint, for example), so it cannot tell how strong the method was or see how anyone actually signed in. This replaces an owner’s “everyone must use two-step sign-in” setting for people who sign in through the company. A person who has any role in another business is asked for their authenticator code if they have one, and otherwise confirms by an emailed link each time. People who sign in the usual ways keep NextUp’s own two-step sign-in.
Can we map our groups to NextUp roles?
Yes, at sign-in. The owner lists the groups that mean manager and the groups that mean staff, and each company sign-in sets the person’s role from them: manager if they are in a manager group, otherwise staff if they are in a staff group, otherwise the default role the owner chose. The owner can also name a custom role (a named set of the manager permissions, such as refunds or team pay) and list the groups that give it: those people become managers with that role, and if they are in the groups of several roles the first role in the owner’s list wins. Move someone to another group and their role follows the next time they sign in, or when your provider pushes the change. An owner’s role is never changed, nobody is removed this way and nobody becomes an owner. Groups your identity system pushes through user sync count too.
Can people start from a tile in our app launcher?
Yes. Point a tile or bookmark in your launcher at the sign-in link on the settings screen. It starts a normal sign-in, and the person lands in NextUp signed in. For SAML, the owner can also turn on a switch (off unless turned on) that lets your provider’s own tile start the sign-in; it then only signs in people who already belong to the business, and the answer must be signed, fresh and used once. If the browser already has a NextUp session open, the person is asked “Continue as …?” and must click Continue before it is replaced. With the switch off, such an answer is ignored and nothing is recorded.
Does NextUp Walk-in have a security certification?
No. We don’t claim SOC 2, ISO 27001 or any other certification. The Security page lists what we do, and what we don’t.
Does it change the PIN on the shared floor screen?
No. A location’s staff PIN for its shared floor screen is separate. Company sign-in is for people’s own sign-ins.
One company login, every shop.
Ask us to turn on single sign-on, and your owner sets it up from the dashboard.