Enterprise SSO — Security & FAQ¶
This page covers the security model behind Vellocity Enterprise SSO and answers common questions about provisioning, domains, enforcement, and provider lifecycle.
What JIT provisioning creates¶
When a teammate signs in through SSO for the first time, Vellocity provisions their account automatically. It's worth being precise about what that does — and doesn't — create.
JIT provisioning creates:
- A Vellocity user account with the identity from your IdP (email, name), marked email-confirmed.
- An assignment to your organization, matched by the email domain on their work account.
- A seat on your organization's plan, if a seat is available — which grants them your plan's capabilities immediately.
JIT provisioning does not create:
- A password you use. SSO accounts get a random, unusable password. Your users always authenticate at your IdP, never with a Vellocity password (unless you also allow password login and they set one).
- An individual subscription or payment method. Billing lives at the organization level — there's no separate Stripe customer or checkout per user. Your organization carries the plan and the seats.
- A way around your IdP's controls. MFA, conditional access, and offboarding all stay with your IdP. Remove a user there and their SSO access to Vellocity stops.
When seats are full¶
If your organization is already at its seat limit when a new user signs in, the default behavior is:
- They still sign in (their identity is valid) but land without a plan — a feature-limited state — rather than being turned away.
- Your organization's billing contact is notified so a seat can be added. When you raise the seat limit, waitlisted users are activated automatically.
You can change this to block sign-in entirely when seats are full, if you'd rather no one in without a seat. Ask your Vellocity contact to set your seat-overflow policy.
Users with no matching organization¶
If someone signs in through a global identity provider whose domain doesn't match any organization (for example a personal email), they get an ordinary free, feature-limited account — the same as a standard self-service signup. They aren't placed in anyone's organization.
Domain matching¶
Two domain settings work together:
| Setting | Where | What it does |
|---|---|---|
| Verified domains | On your organization | Auto-assigns a signed-in user to your organization when their email domain matches. Drives seat provisioning. |
| Allowed domains | On your identity provider | Restricts which email domains may authenticate through that provider. A sign-in from an unlisted domain is rejected. |
Together they ensure that only your people, on your domains, land in your organization.
SSO enforcement¶
By default, a user whose organization uses SSO can still sign in with a Vellocity password if they have one. If you'd rather require SSO, your organization can enable SSO enforcement. Enforcement is an Enterprise-plan feature (SSO login itself is available on Accelerate and above).
When enforcement is on:
- Password login is blocked for any email on your organization's verified domains — those users are redirected to sign in through your IdP.
- Break-glass admins stay exempt. A small set of designated administrators can always sign in with a password, so a misconfigured or temporarily unavailable IdP can never lock your organization out. See below.
Break-glass admins (lockout prevention)¶
If SSO enforcement is on and SSO itself breaks — an expired certificate, an IdP outage, a misconfiguration — the only way back in is a break-glass admin: a designated user who is exempt from enforcement and can sign in with a password.
- Designate more than one. The organization owner is always a break-glass admin, but relying on one person is risky — they could leave the company or be on vacation when you need them. We recommend naming at least two break-glass admins.
- They need a usable password. Accounts created through SSO have no usable password, so a break-glass admin should set one via password reset ahead of time, so it works when SSO doesn't.
- Enforcement can't be enabled without one. Vellocity won't let SSO enforcement be turned on unless at least one break-glass admin has an active account — this prevents accidentally locking everyone out.
- Last resort. If every break-glass admin is somehow unavailable, the Vellocity team can disable enforcement for your organization. Contact support@vell.ai.
Ask us to enable enforcement
SSO enforcement and break-glass admins are configured with the Vellocity team as part of your organization setup. Tell your contact when you're ready to require SSO for your domains — and who your break-glass admins should be.
Rotating or removing a provider¶
- To rotate an IdP (for example after a certificate change or migrating IdPs): register the new provider and metadata, verify a test sign-in works, then remove the old one. Registering a new provider doesn't disturb existing signed-in sessions.
- To remove a provider: when a provider is deleted, Vellocity also removes it from the underlying Cognito app client automatically, so there's no dangling federation left behind. Users who were provisioned through it keep their accounts (and their organization membership) but can no longer sign in through that provider.
Sessions & sign-out¶
Every SSO sign-in is recorded — the identity provider used, the time, IP address, and user agent — for visibility and audit. Signing out of Vellocity ends the Vellocity session; depending on your IdP's single-logout configuration, it may also end the session at your IdP.
Trust¶
Your identity provider remains the authority for your users at all times, and Vellocity never sees or stores their IdP password. Our SOC 2 audit is in progress. For the current security and governance posture, talk to your Vellocity contact.
FAQ¶
Do our users need a Vellocity password? No. SSO users authenticate entirely at your IdP. A Vellocity password is only relevant if you also allow password login and a user sets one.
What happens when we offboard someone in our IdP? Their ability to sign in through SSO stops immediately, because your IdP is the authority for the federation. To also free their Vellocity seat, remove them from your organization.
Can one organization have more than one identity provider? Yes — for example during an IdP migration, or to federate more than one directory. Each provider is scoped to your organization and its allowed domains.
Can we use both SSO and password login? Yes, unless you turn on SSO enforcement, which blocks password login for your domains (except your break-glass admins).
What if the person who set up SSO leaves the company? As long as you've designated more than one break-glass admin, the others can still sign in and recover the account. This is exactly why we recommend naming at least two. If every break-glass admin is unavailable, Vellocity support can disable enforcement for you.
Is self-service setup available? Not yet. Federation is admin-assisted today; self-service configuration is on the roadmap. See the onboarding guide for the current flow.