SSO RFP questions

There is no fixed number that fits every organization, so the right count comes from the inventory and the written phase plan, not from a general rule. A capable partner should give you a phase plan that lists which applications move in each phase, the protocol each one uses, the owner who signs off, and the dependencies between them. Early phases usually cover a small set of low-risk, well-understood applications so the team can prove the pattern. Later phases carry the harder integrations. Ask the partner to show the count per phase in the proposal and to tie each phase to a scope statement that you can approve before work starts.

An inventory is the foundation of the phase plan, and a good one records more than application names. For each application, ask for the business owner, the technical owner, the protocol it supports (SAML 2.0, OpenID Connect, OAuth 2.0, LDAP or none), the user population, how users are provisioned and removed today, whether it has its own local accounts, its data sensitivity, and whether it sits behind a proxy or on a network segment that the identity provider can reach. Include applications that cannot use SSO at all, since those need a separate plan. The partner should explain how they will verify the inventory against network logs, existing directory groups and the service catalog, because owners often forget tools that staff use daily.

Sequencing usually starts with applications that use standard protocols, have clear owners, and do not gate other systems, then moves toward those that handle regulated data, depend on other applications, or require coordinated changes by a vendor. Dependencies matter because a single application may need a directory group, a claim mapping or a certificate that another system already consumes. Ask the partner to produce a dependency map and a risk rating for each application, and to explain what happens if a phase slips. A useful answer names the rollback method for each phase, such as keeping local login available for a defined period, and states who approves moving to the next phase.

Done should be defined per application in writing before the work begins, not decided at the end. A practical acceptance definition covers successful login for a defined set of test users, correct group or role mapping, working logout, session timeout behavior, MFA enforcement where the policy requires it, and removal of access when a test account is disabled in the source directory. It should also state where the configuration is recorded and how the owner signs off. Ask the partner for a sample acceptance checklist and for the test evidence they keep, such as exported configuration, test logs and screenshots of results.

Testing should run in a non-production realm or environment that mirrors the production client configuration, followed by a limited pilot with named users before the general cutover. Testers should include application owners, not only the integration team, because business owners know which workflows matter. Cover the paths that break most often, including first login, password or MFA reset, role changes, expired sessions, and API or mobile clients that do not use a browser. Ask the partner how they record results, how defects are triaged, and whether they re-run the test set after upgrades to the identity platform or the application.

Yes, many teams split the work: internal staff own the inventory and business sign-off, while a partner builds the integration pattern, the test harness and the runbooks. The split should be written into the scope so each side knows who performs each task and who approves it. Ask the partner which tasks they would hand over, what knowledge transfer is included, and what your team needs to maintain the phase plan after the engagement ends. Cost follows the number of applications, their protocol complexity and the amount of coordination with application vendors, so a fixed-scope quote should itemize those components.

Several factors shift the count: the protocol support of each application, whether the vendor must change settings, whether the app depends on directory attributes that do not exist yet, the number of user groups involved, and how many business units must approve the change. Applications with a SAML or OpenID Connect option are usually quicker than those that need a proxy or a custom connector. The partner should state these assumptions in the phase plan and show how a change to any one of them moves an application to a different phase. Ask them to list the assumptions as part of the written scope so both sides can track changes.

Each integrated application should leave a record that an operator and an auditor can both use. Ask for the client configuration export or a documented equivalent, the group and role mapping, the acceptance checklist with signed results, the rollback procedure, and the list of users or groups granted access at cutover. Where the identity platform is Keycloak, the partner should be able to show the realm and client settings in a repeatable form, such as a configuration file kept under version control. Confirm the format and storage location in writing so the records remain available after the project closes.

Keycloak plans four minor releases a year and a major release every two to three years, according to the project's October 2024 release update post. The project says breaking changes in a minor release are opt-in, so a routine minor upgrade should not change behavior until you enable them. That is a planning assumption, not a guarantee. Each upgrade still needs a review of the release notes against your realms, custom authenticators, themes and protocol mappers before it goes anywhere near production. Ask your implementation partner which release line they will pin to and how long they will keep it under support.

A useful staging environment matches production in the things that change login behavior: the Keycloak version and deployment topology, the database engine and version, the cluster size, the TLS certificates and hostnames, and the federated directories such as LDAP or Active Directory. It also needs copies of your realm configuration and a representative set of test clients for each protocol you run, including SAML and OIDC applications. Data does not need to be a full copy of production, but test identities should cover the directory attributes, group memberships and MFA states your real users have. Ask the partner to document every known difference between staging and production and to close the gaps that affect authentication.

A regression suite for workforce SSO should cover the login paths that users and applications actually depend on:

• Browser login with password and with each MFA method you enforce, including passkeys where enabled
• Token issuance and refresh for each OIDC client, and SAML assertion exchange for each SAML application
• Logout, session expiry and single logout behavior
• Directory federation, group mapping and attribute release into applications
• Admin console actions used by your help desk, such as unlocking accounts and resetting MFA
• Brokered logins from any external identity provider you trust

The suite should be automated where possible so it can run in staging for each candidate version. Ask the partner who owns these tests, where the results are stored, and what must pass before a change is approved.

Keycloak migrates its database schema automatically at startup by default. For large deployments, the upgrading guide suggests manual migration instead, where administrators apply the SQL themselves after reviewing it. Manual migration gives your database team a chance to review the changes, schedule locks and confirm backups before the new version starts. Ask the partner which approach they will use for your database size, whether they will take and test a database backup before each migration, and how they will confirm the schema matches the expected version after cutover.

The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, so that an upgrade does not happen without someone deciding it should. In practice, the operator version and the Keycloak image version should be promoted together through staging, with each change recorded in your change management system. Automatic updates may be acceptable for development clusters, but production should move only after the test suite passes. Ask the partner how operator updates are approved, who holds that approval, and how they are rolled back if a new operator version misbehaves.

A rollback plan should state the exact previous image and operator versions, a tested restore path for the database, and the decision point after which rollback is no longer simple because users have created new sessions or changed data. Rehearse the rollback in staging before the production change, and record how long it took and which steps needed manual work. Keep a break-glass administrator account and a documented way to reach the login page if the identity provider is unavailable. Ask the partner to provide the written rollback runbook as a deliverable, with named owners for each step.

Your partner should state which platform versions they support, how long each line receives security fixes, and how quickly they will move you off a version that is near end of support. For Keycloak, the project releases several minor versions each year, so a policy should say which minor versions are pinned and how often you move. For other platforms such as authentik, the vendor publishes its own list of supported versions and security release notice periods, which the partner should monitor. Ask for the written policy, the process for emergency security patches, and whether support covers upgrades or only incident response.

An internal team can run an upgrade test cycle if it has staging parity, automated login tests, someone who reads release notes closely and a documented rollback. The effort depends on how many applications and directories you connect, how many custom extensions you maintain, and how often you upgrade. Costs recur with each release cycle, so the question is whether staff time for every upgrade is available. Ask a partner to quote the test and upgrade work as a fixed scope with written deliverables, and compare that with the internal hours your team would need to keep the same coverage.

The biggest cost drivers are the number of applications to integrate, the protocols each one speaks, and how many directories must be federated. A project with a handful of modern OIDC applications and one directory costs far less to integrate than one with dozens of SAML apps, LDAP-bound legacy systems and custom logins. Infrastructure, database high availability, MFA rollout, testing, documentation and ongoing support add further components. Keycloak, authentik and ZITADEL core software is free to download, so the spend is mostly labor, hosting and support. Ask any partner to split the quote by application, directory, MFA, high availability and support so you can see which line moves when scope changes.

Duration depends on the written scope, so no general timeline applies. The main variables are the number of applications per phase, how many legacy systems need a workaround, whether MFA enrollment must reach every staff member, and how many environments (test, staging, production, disaster recovery) must be built and validated. A phased plan that starts with a pilot group and a small set of high-value applications usually lets the team learn before the wider rollout. DeployOpen does not publish a price list or a fixed duration; a quote and schedule follow from the scope, which is agreed in writing before work starts.

Yes, if your organization needs features that sit in the Enterprise tier. The authentik pricing page lists the Open Source edition as free with community support only, Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise-only features on that page include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support. Confirm current pricing directly with authentik, because the page can change. Model the per-user cost against your headcount and external user count before deciding which edition your requirements need.

Several costs continue after launch. Hosting and compute for the identity provider, its database and any clustered nodes recur every month. Security patching and version upgrades recur, and Keycloak's project plans four minor releases a year, so budget for regular upgrade testing. Support, whether an internal rota or a retainer with a partner, is ongoing. Commercial subscriptions, such as paid open-source editions or enterprise support tiers, also recur, typically annually or per user. One-time costs include design, integration of each application, initial MFA enrollment and documentation. Ask the partner to label each line item as one-time or recurring so you can compare build, partner and SaaS options on equal terms.

Many organizations with strong platform and identity engineers can build and run Keycloak, authentik or ZITADEL in-house. The questions to answer honestly are whether you have people who can design high availability with a synchronously replicated database, test upgrades before production, integrate each application's SAML or OIDC settings, and handle an outage at 2 a.m. If the answer is yes for most of these, the in-house route may suit you. If not, a partner can fill specific gaps, such as architecture review, application integration or hardening, under a fixed-scope agreement. Many teams split the work this way, keeping operations in-house while the partner covers the parts they lack.

A partner needs named people from your side with decision authority and enough time to answer detailed questions. Typically this includes an application owner for each system to be integrated, someone who can grant access to the directories being federated, and a security or compliance lead who can confirm MFA, session and audit requirements. The partner will also need access to your cloud accounts, data centers or isolated networks where the platform will run, plus change windows for production cutover. Agree on these inputs in the written scope so that delays caused by missing access or unavailable owners are visible early.

A useful quote lists the scope in writing: the applications and protocols in each phase, the directories to federate, the MFA and passkey policy, the high availability design, environments to build, testing and upgrade procedures, documentation, training and handover. It should separate one-time implementation work from recurring support or retainer fees, and it should state which third-party subscriptions, if any, are the client's responsibility. Ask what is excluded, such as legacy applications needing custom work, and what changes cost if requirements expand. DeployOpen does not publish a price list. A quote follows from the written scope, so the more precise the requirements, the more precise the quote.

Not always, but it usually increases effort and risk. Modern applications that already support OIDC or SAML can often be integrated quickly from a template, so a large number of them may take less time than a few heavily customized legacy systems. The effort rises sharply with applications that need LDAP binds, header-based authentication, custom session handling or local accounts that must be kept in sync. Group applications by protocol and complexity during scoping, then sequence the simplest first. This shows the true effort early and lets you choose whether to modernize, wrap or retire the hardest systems.