SSO implementation cost: what a single sign-on retrofit across your existing apps takes, phase by phase

What drives SSO implementation cost for apps you already run?#

SSO implementation cost is set by your app inventory: apps that already speak OIDC or SAML need configuration, while apps with their own login form need code and user-record work. So the licence is the smaller line, and the easier one to read. Licence list prices, pricing units and the "SSO tax" on vendor plans are in our guide to SSO and identity platform pricing. This guide prices the project around them.

Take a worked example of a suite of 12 apps. Four already speak OIDC or SAML. Three older on-premises apps can take a login header from a proxy. And five keep their own login form and user table. Configuration covers the first four, while the middle three need a proxy and a test pass. Then the last five need code in each app, a merge of their user tables and a careful cutover. So most of the weeks go there.

Retrofits like this have measured outcomes. For example, our case study of a Keycloak sign-on migration, published in March 2026, records several application logins becoming one sign-on. Keycloak is an open-source identity server. On that engagement, users from each app moved into one central user store with no downtime. As a result, authentication support tickets fell 70% in that March 2026 study, measured on that one project.

Which apps in your suite are cheap to connect, and which are not?#

Sort every app by how it signs users in today, because each route, from a configured OIDC client to a header proxy to a rewritten login form, carries different work. There are four classes, and each app lands in one.

OIDC apps: configuration#

First, an OIDC app sends the user to the identity provider and gets a code back. An identity provider (IdP) is the service that holds the accounts and checks the password. The OpenID Connect Core specification calls this route the Authorization Code Flow. Then the app swaps the code for tokens on its own server.

SAML apps: configuration and a certificate#

Second, a SAML app works the same way, with a signed message in place of a code. In Okta's SAML guide, the service provider (SP) is defined as "The entity providing the service, typically in the form of an app". Okta calls the common case an SP-initiated sign-in. It is "typically triggered when the end user tries to access a resource or sign in directly on the SP side."

Header or proxy apps: a proxy in front#

Third, some older apps trust a header set by a proxy in front of them. Microsoft Entra ID is Microsoft's cloud identity service. Its header-based SSO page says: "Microsoft Entra application proxy natively supports single sign-on (SSO) access to applications that use headers for authentication." So these apps change little.

Apps with their own login form: code#

Fourth, an app with its own login form and user table has no hook for any of this. So someone adds an OIDC or SAML client in code and links the old accounts to the new identities. Then every role gets tested. That is why this class carries the highest SSO integration cost per app.

Source: Kolonell, "Microsoft Entra SSO Integration Cost, New York 2026", indicative timelines, read October 2026; one agency's published estimate, not a measured average.

Where should user records live, and how do duplicate accounts get merged?#

Pick one identity source of truth before connecting any app, because duplicate accounts across apps must be matched, merged or federated before a single login can work. In practice, one person often has three accounts under two email addresses. So the merge is its own workstream, with an owner and a test plan.

1. Pick one identity source of truth

   Pick one identity source of truth before connecting any app, because duplicate accounts across apps must be matched, merged or federated before a single login can work.

2. Federate the old user stores

   Old user stores stay in place while the merge happens.

3. Write the dedupe rules down

   Decide which field matches two records and which app wins a conflict. Also decide what happens to an account with no match.

4. Run a week of coexistence

   Kolonell's 2026 Toronto page suggests one week of coexistence before turning off password login.

Federation is the way round a big-bang move. The Keycloak Server Administration Guide says: "Typically, you cannot migrate existing data storage to a Keycloak deployment so Keycloak can federate existing external user databases." That guide covers Lightweight Directory Access Protocol (LDAP) directories and Active Directory, Microsoft's directory of company accounts. Keycloak can also sync those users in. So old user stores stay in place while the merge happens.

Then write the dedupe rules down. Decide which field matches two records and which app wins a conflict. Also decide what happens to an account with no match. Kolonell's 2026 Toronto page says linking accounts by email "happens automatically in minutes". It also suggests one week of coexistence before turning off password login. But that holds only where emails are clean, so count the exceptions first.

If your apps run on Laravel, a popular web framework, our walkthrough of moving Laravel users into Keycloak covers the migration code step by step. This guide stays with the plan and the budget.

What do MFA and session rules add to the rollout?#

NIST SP 800-63B-4 caps reauthentication at no more than 24 hours at AAL2 and 12 hours at AAL3, so your session policy is a decision, not a default (read October 2026). NIST is the US National Institute of Standards and Technology. An authenticator assurance level (AAL) says how sure a sign-in is. At AAL2 the 24 hours is a SHOULD, and at AAL3 the 12 hours is a SHALL.

Multi-factor authentication (MFA) asks for a second proof, such as a phone prompt or a security key. At AAL2, NIST SP 800-63B-4 says sign-in "SHALL use either a multi-factor authenticator or a combination of two separate authentication factors." The same 2026 reading of NIST says the AAL2 inactivity timeout should be no more than 1 hour. So every app behind the new login must honour one timeout policy. Otherwise users get prompted twice.

MFA enrolment also has to finish before the cutover, not during it. For instance, the University of Delaware's IT blog of 25 June 2026 asked all faculty and staff to enrol in Microsoft MFA before its October 2026 move. That move retires Central Authentication Service (CAS) and Shibboleth, two older campus sign-on systems. So enrolment is a communications task with a deadline, and it belongs on the timeline.

How long does SCIM provisioning take before deprovisioning can be trusted?#

Microsoft documents an initial provisioning cycle of 0.01 to 0.08 minutes per assigned user, group and member, so a large directory needs hours before offboarding is reliable (read October 2026). System for Cross-domain Identity Management (SCIM) is the standard application programming interface (API) an identity provider uses to create, update and remove accounts in each app.

The formula is simple. Minimum minutes equal 0.01 times the assigned users, groups and members, and maximum minutes equal 0.08 times the same count. Say a directory holds 50,000 assigned objects: the formula then gives 500 to 4,000 minutes, or about 8 to 67 hours. Until that first cycle ends, an account removed in the directory may still work in an app.

Deprovisioning is where SCIM pays for itself. RFC 7644, the 2015 Request for Comments that sets the SCIM protocol, defines a DELETE request that removes a resource. Microsoft's provisioning overview adds that automatic provisioning covers "the maintenance and removal of user identities". So budget SCIM for each app that supports it. And keep a manual offboarding checklist for the apps that do not.

How do you cut over in stages without locking anyone out?#

Move apps in waves behind a pilot group, keep the old login reachable as a fallback for each wave, and define the signal that rolls a wave back. Microsoft's migration guide describes the pilot group this way: "Users who test as a part of their daily work". Kolonell's 2026 New York page suggests a pilot group of 20 users per app.

1. Start with a pilot group

   Move apps in waves behind a pilot group.

2. Keep the fallback login

   Keep the old login reachable but hidden, so a pilot user who hits a broken role can still work.

3. Name the rollback trigger

   Name the rollback trigger before the wave starts. For example, sign-in failures over an agreed share or a broken role mapping.

The fallback is what makes a wave safe. Keep the old login reachable but hidden, so a pilot user who hits a broken role can still work. Then name the rollback trigger before the wave starts. For example, sign-in failures over an agreed share or a broken role mapping. Once the trigger is written down, rolling back is a routine call, not a debate during an outage.

Public rollouts follow this order. NC State's IT office lists Google Workspace moving from Shibboleth to Entra ID from 14 September. Then Zoom and Moodle follow at fall break, and its MyPack Portal in mid-November. After that, smaller systems migrate gradually through the end of 2026. So it is a big-apps-first wave plan.

How long does an SSO rollout take, phase by phase?#

An SSO rollout runs as discovery, identity cleanup, app waves and decommission, and its length is set by the slowest class of app in the inventory. Microsoft's migration overview says: "The process is broken into four phases. Each phase contains detailed planning and exit criteria". Its four phases are Discover and Scope, Classify apps and plan pilot, Plan migration and testing, and Manage and gain insights.

The app waves dominate the calendar. In Kolonell's 2026 New York estimates, each app takes 2 to 4 weeks including acceptance testing. Worked in parallel, a suite takes 6 to 10 weeks there. And that page adds 1 to 2 weeks for SAML on legacy apps. As a result, five apps with their own login form usually decide the end date. The four that only need configuration rarely do.

Large suites take longer because the tail is long. NC State's project page, read in October 2026, says it had used Shibboleth for 18 years. It moved its biggest systems in one autumn and gave smaller ones until the end of 2026. So plan the calendar from the slowest class. Then add the merge and MFA enrolment in front of it.

What does SSO cost to run after go-live?#

Microsoft puts federation certificate lifetimes at typically 1 to 3 years, so every SAML app carries a rotation date someone must own after go-live (read October 2026). Microsoft's certificate tutorial says "These certificates expire (typically every 1-3 years)".

Microsoft's SSO deployment plan adds that "Microsoft Entra ID creates a certificate that is by default valid for three years". It also asks for a named certificate rollover owner. And it asks for a closely monitored email list for certificate notices. So with eight SAML apps, someone owns eight rotation dates. If one is missed, that app's users are locked out.

Then come upgrades and on-call. A self-hosted identity server needs version upgrades, and every upgrade needs a test pass across the connected apps. Also, the sign-in path becomes the one service every app depends on. So it needs an on-call owner. Finally, each new app that joins the suite repeats the triage, on a smaller scale.

What does a retrofit cost at three company sizes?#

Project cost scales with the count of apps that keep their own login form, so the estimator below multiplies your count per class by your own effort per app. Kolonell's 2026 New York estimates give 1 to 2 weeks for an OIDC login and 1 week of account rework per app. So an own-login app takes about 2 to 3 weeks before suite-wide testing.

Three illustrative suites#

Take three illustrative suites. Say a small company has 5 apps, and only one keeps its own login form. Then the mid-size case is the 12-app worked example, with five own-login apps. And say a large company has 40 apps, fifteen own-login apps and 50,000 directory objects.

Illustrative suites; first-sync minutes from Microsoft's formula of 0.01 to 0.08 minutes per assigned object, Microsoft Learn, 4 March 2025.

In the mid-size worked example, five own-login apps at 2 to 3 weeks each come to 10 to 15 app weeks. That is before SCIM, testing across the suite and run cost. So the single sign-on implementation cost of the suite is those weeks times your team's own rate. Use it as a method, then put in your own figures.

What a public record shows#

Public records show the other side of the bill. The State of Hawaii's Office of Enterprise Technology Services (ETS) published a project summary for its Single Sign-On Support amendment in May 2024. In that record, ETS dropped Azure B2C, Microsoft's customer sign-in service, for ForgeRock Ping Identity, another identity platform. The Hawaii ETS record of May 2024 says the change's development cost of $24,188.47 is in addition to the existing development fee of $528,868.90, both in US dollars. That larger fee covers the wider engagement, so it is not the cost of SSO alone.

Should you build it in-house or with a partner, and what usually goes wrong?#

Build in-house when your team already runs the identity provider and owns every app; bring a partner when apps with their own login forms outnumber the people who know them. Both routes run the same phases. So compare them on the same three points.

In-house wins when the app owners are on staff and the suite is mostly OIDC and SAML apps. Its weak spot is time, because the people who know each login form are also shipping features. A partner wins when many own-login apps need code at once. Its weak spot is handover. Certificates, upgrades and on-call stay with you after the project ends.

Three failures recur in public records and vendor guides. First, the identity provider changes mid-project. In Hawaii's record, the move to ForgeRock Ping Identity pushed production launch to February 2025. Second, a SAML certificate with no owner expires on a weekend. Third, a cutover has no fallback login, so one broken role locks a team out. For the platform choice itself, our Keycloak vs Auth0 cost comparison prices both options over three years, with Auth0 as the hosted identity service.

When is a full SSO retrofit the wrong fit?#

A full retrofit is the wrong fit when an app is due for retirement within a year or has a handful of users, because a shared vault or a proxy costs less than code work. Here are three cases, each with a better route.

First, an app due for retirement within a year should keep its own login until it goes. Code spent on its sign-in is lost when it is switched off. Second, an app with a handful of users and one shared account can use a password vault. Microsoft's SSO deployment plan describes automatic rollover of a shared account's password. That way, "not even the administrator who did the initial setup knows the password".

Third, an on-premises app that already trusts a login header belongs behind a header proxy, not in a rewrite. Microsoft's header-based SSO page covers that route directly. Also, if a vendor app offers SSO only on a pricier tier, compare that licence step against the work first. The pricing guide linked above covers those tiers.

Where to go from here#

Start with the inventory, then take licence prices, platform choice and user migration from the posts that cover each one in depth. A spreadsheet with one row per app is enough to begin an SSO implementation cost estimate. Give each row its sign-in route, its user count and its owner.

For licence prices and the SSO tax, read our guide to SSO and identity platform pricing. Then, for the platform choice, see the Keycloak vs Auth0 cost comparison. And for the user migration code, the Laravel Keycloak user migration walkthrough goes step by step.

If you want help with the security side of the rollout, our security and compliance work covers SSO, MFA and access control. When the apps themselves need connecting, our API integration work covers that. Either way, the Microsoft, Okta, Keycloak and NIST pages linked above are enough to plan the whole retrofit on your own.