Federal SSO needs cost predictability, not another opaque renewal

Most federal teams learn that single sign-on (SSO) is infrastructure on a bad day rather than during procurement. A citizen portal stops accepting logins the week a filing deadline hits, a certificate that connects a partner agency expires overnight, or contractors lose access to the systems they need because an identity provider upgrade did not go as planned. In each case, the login page is only the part people see. Underneath it are decisions about who controls the user information passed to each application, how extra verification is triggered for risky actions, whether upgrades are practiced before they go live, and whether the agency could move to another provider without rewriting every application connected to it.

For a long time, many agencies bought SSO and customer identity the way they would buy a convenience service. The appeal was speed: connect the portal, add partner agencies, switch on multifactor authentication, and renew every year. The trouble is in how that kind of product is usually priced. Most vendors charge per user or per monthly active user, so the bill grows whenever more people log in. When a program succeeds and usage goes up, the renewal goes up with it, even if the systems behind the login have not changed at all. We saw this recently with a consumer company whose app took off faster than planned: its bill grew with every new user, the enterprise features it needed sat in a higher tier, and it ended up switching providers under time pressure. Finance ends up shaping identity decisions without meaning to, and renewal meetings turn into discussions about user tiers instead of risk and how hard it would be to leave.

Per-user pricing is a reasonable model for some buyers, but it fits federal usage patterns badly. Citizen portals see large spikes around tax deadlines and benefit enrollment windows. Partner connections grow each time a new state system or another agency joins. Contractor accounts rise and fall with task orders. Under per-user pricing, each of those normal events shows up as a cost increase. Pricing based on capacity or load works more like the way agencies already budget for servers and databases: you plan for the peak you expect, you budget for running it, and a busy month does not reopen the contract.

The cost question and the operations question are connected. Identity is often treated as a project that is finished once the login works, when in practice it is a production system that every other application depends on. When SSO or multifactor authentication fails, users do not see an identity problem. They see a portal that is down, a partner integration that stopped working, or contractors who cannot do their jobs. That is why identity deserves the same treatment as the database, with a named owner, a change calendar, and a measure of success that goes beyond the feature having shipped. Four areas deserve as much attention as the login page.

The first is control of user attributes. When someone signs in, the identity system sends each application a small set of facts about them, such as their role or their agency, and the application uses those facts to decide what the person is allowed to do. If the agency cannot change those mappings itself, in a place that is audited, then every application change becomes a request waiting in a vendor’s queue.

The second is step-up verification. Basic multifactor authentication is now expected, and the National Institute of Standards and Technology’s digital identity guidelines (Special Publication 800-63) ask agencies to match the strength of proof to the risk involved. Changing the bank account on a benefits claim or approving a high-impact workflow should require stronger proof at that moment. Making that work reliably, including a recovery path for people who lose their phone or security key, is ongoing operational work rather than a policy written once.

The third is practicing upgrades. Identity upgrades should be scheduled work, tested in a staging environment that resembles production in the amount of data and in the partner connections it has, with a go or no-go decision owned by a named person. A staging environment with almost no data in it will hide the problems that later appear in production. The same process should cover security patches, which means someone has to be watching the vendor’s advisories and have a maintenance window ready when one lands.

The fourth is leaving. The time to plan an exit from an identity provider is before signing with one. Agencies should know whether they can export their users, applications, and partner configuration in documented formats, whether they can run the old and new systems side by side while applications move over, and whether they can take full backups on their own schedule. A vendor that answers these points in writing before the contract is signed is much easier to live with later.

Open-source identity providers, such as Keycloak, are worth considering with this in mind, because their configuration can be exported and moved in documented formats. They are not free to run, since someone still has to operate, patch and upgrade them, whether that is the agency’s own staff or a managed provider. What they change is who owns the configuration, and owning it is what makes an exit realistic.

Procurement language can help. Solicitations can ask for pricing tied to capacity or load instead of only per-user tiers, and can require written answers on export formats, running old and new systems in parallel, multifactor recovery, and who controls attribute mappings. Budgets can set aside hours for upgrade rehearsals the same way they do for major database upgrades. Programs can track multifactor coverage and certificate expiry dates alongside their other production dependencies, and can treat removing contractor access as part of offboarding rather than something discovered months later.

Citizen portals, partner connections, and contractor access will keep growing for as long as programs succeed. Agencies can let that growth arrive as surprise renewals and unplanned outages, or they can buy and run identity as infrastructure they own, practice changing, and could leave if they needed to. Predictable cost is a large part of what makes the second path possible.

Guilliano Molaire is the founder of Skycloak.