Procurement: Identity and Auth Services
What this is and who it’s for
This runbook tells you how to buy identity and authentication services — an identity provider (IdP), customer/citizen identity (CIAM), or workforce single sign-on (SSO) — on a Maryland contract vehicle without overpaying or getting locked in. It’s for an agency tech lead who needs the capability and the procurement officer who has to put it on a contract. It assumes you already know your identity architecture; the job here is converting that into a defensible requirement, the right vehicle, a SOW you can stand behind, and an evaluation that picks a tool on merit. Citizen-facing identity and workforce identity are different buys with different cost shapes and risks — do not let a single vendor talk you into solving both with one product. If you can’t yet say whether you’re buying citizen CIAM or workforce SSO, stop and read the prerequisites first.
Prerequisites
- You’ve read the Reference Identity Architecture and can name your identity boundaries: who authenticates, where accounts live, and which systems federate to which. You cannot write a defensible requirement for an architecture you can’t draw.
- You know whether this is citizen/CIAM or workforce SSO. These are different products, different pricing models, and often different vehicles — settle it before you price anything.
- You have an estimate of user volume. For citizen identity this is monthly active users (MAU), which is the dominant cost driver and the most common budget surprise — get a real number, not a guess.
- You’ve determined your identity-proofing and assurance requirement — whether you need NIST 800-63 IAL/AAL levels, and at what level [VERIFY]. Proofing requirements narrow the vendor field and change the cost, so settle them up front.
- You know which protocols you must support: OIDC, SAML for federation, SCIM for provisioning [VERIFY]. Protocol support is a pass/fail gate, not a nice-to-have.
The practice
Run this as four moves in order: define the requirement, pick a vehicle, write the SOW, evaluate. The citizen-versus-workforce distinction is the hinge decision — it changes the vehicle, the SOW, and the cost shape — so make it explicitly rather than letting a vendor blur it.
Define the requirement
Write down five things before you talk to anyone: the population (citizen or workforce), the user volume, the proofing/assurance level, the protocols, and the data-residency posture for any PII. State the population first, because it splits the entire buy: citizen identity is priced per monthly active user and lives on the public internet; workforce identity is priced per seat and lives behind your perimeter. Set the assurance level explicitly — IAL/AAL per NIST 800-63 [VERIFY] — since identity proofing is a cost and capability driver, not an afterthought. Capture user volume as a number with a growth assumption, because per-MAU pricing turns a successful citizen launch into a budget crisis. Name the required protocols (OIDC, SAML, SCIM) [VERIFY] as testable requirements, not preferences.
Map the capability to an option
Commercial CIAM / IdP SaaS (citizen-facing)
A vendor-hosted customer-identity platform built for public, internet-scale signup and login (named category, not an endorsement). Fastest path to a citizen login and the least to operate. Procurement angle: this is a subscription service, and per-MAU pricing is the trap — a free or cheap tier at pilot volume becomes the largest line in your budget at citizen scale, so require pricing in writing at projected and +100% MAU. The platform must carry the required FedRAMP/StateRAMP authorization [VERIFY] and its hosted login flows must meet Section 508 / WCAG [VERIFY 508], because you cannot remediate accessibility on a UI you don’t control.
Enterprise SSO / IdP (workforce)
A vendor-hosted identity provider built for employee SSO, directory integration, and lifecycle provisioning. Priced per seat or per employee, which is predictable and bounded — unlike per-MAU, your workforce doesn’t scale with public adoption. Procurement angle: a subscription service that usually maps cleanly to an existing IT-services or software vehicle; the deciding terms are SCIM provisioning, SAML/OIDC federation to your apps, and the authorization level [VERIFY]. Do not buy this product to serve citizens — workforce IdPs price and scale badly against an internet-sized population.
Shared / federated government identity service
A government-operated identity service you federate to rather than procure as a product [FILL IN: Login.gov / Maryland statewide IdP — confirm availability and eligibility]. The agency consumes identity assurance and proofing from a shared service instead of buying and operating its own, which can remove the buy entirely. Procurement angle: this may be an interagency agreement or a no-cost/cost-shared arrangement rather than a competitive procurement [VERIFY] — confirm whether your use case is eligible and what assurance levels the service offers [VERIFY] before you assume it fits. If it fits, it is almost always the lowest-risk citizen-identity path because the shared service owns proofing, accessibility, and authorization.
Self-hosted open-source IdP
You run the identity stack (for example Keycloak — named as an example, not an endorsement) on your own infrastructure. No per-user licensing and full control over data residency, which simplifies the PII story because identity data never leaves your boundary. The cost moves from license to labor: the procurement is for implementation and managed-operations services plus compute, not for the software, and you own the accessibility and authorization burden for the login UI yourself. Budget for the people who will run it and keep it patched; an unpatched IdP is a breach waiting to happen.
Map to a vehicle
Match the option to the smallest vehicle that fits. A workforce SSO subscription under the small-purchase threshold [VERIFY] may not need a full RFP; a citizen-scale CIAM contract will. Self-hosted implementation is a services buy and may fit a master services vehicle, while a shared government identity service may need no procurement vehicle at all — only an interagency agreement [VERIFY]. Confirm the candidate vehicles in Procurement notes before committing.
Write the SOW
Fork the skeleton in Reference implementation. Keep user volume, the MAU pricing model, protocols, proofing level, accessibility, and authorization as explicit, testable requirements — not preferences. Put data ownership, exit, and user-migration/portability in writing every time: with identity, your users’ accounts are the lock-in, so an exit without account portability is no exit at all.
Evaluate
Score against the published rubric, not against the demo. Weight authorization, accessibility, and user-data portability as gates: a tool that fails any of them is out, however polished the login screen looks. Run your MAU number through each vendor’s pricing model and evaluate cost at projected and +100% volume, not at pilot volume.
Reference implementation
Fork this SOW skeleton. Every bracketed item is a decision you must make or a value a human must verify; do not ship it with placeholders intact.
# STATEMENT OF WORK — IDENTITY AND AUTHENTICATION SERVICES
### 1. Scope
The Contractor shall provide [citizen CIAM subscription | workforce SSO subscription | implementation and managed operations for a self-hosted IdP] for [AGENCY / SYSTEM]. Population: [CITIZEN | WORKFORCE]. Estimated volume: [N monthly active users (citizen) | N seats (workforce)] with a [N%] annual growth assumption. Term: [base period + option years].
### 2. Protocols and Integration
The platform shall support, as testable requirements:
- OIDC for application authentication.- SAML 2.0 for federation with [in-scope relying parties].- SCIM 2.0 for automated user provisioning/deprovisioning [if workforce].- Standards-based MFA at [required AAL] for [population].
### 3. User Volume and Pricing Model
Pricing shall be stated at the Section 1 volume AND at [+100%] of that volume, so cost growth is visible before award. For citizen identity, the unit of pricing shall be defined explicitly: [how MAU is counted — e.g. distinct authenticated users per month]. [FILL IN: ceiling / NTE amount per agency budget authority.] No per-user overage shall apply without [N days] written notice.
### 4. Identity Proofing and Assurance
The service shall support identity proofing at [NIST 800-63 IAL/AAL level] for [population/use case]. The Contractor shall describe its proofing workflow, accepted evidence, and remote-vs-in-person options.
### 5. Accessibility
All hosted authentication, registration, and account-recovery flows shall conform to Section 508 / WCAG [2.1 AA]. The Contractor shall provide a current VPAT and remediate defects within [N days]. Inaccessible login flows are a pass/fail gate, not a punch-list item.
### 6. Security and Authorization
The service shall hold [FedRAMP | StateRAMP authorization at IMPACT LEVEL] for the term. Citizen PII shall be stored in [data-residency requirement — e.g. U.S. only]; the Contractor shall describe encryption, access control, and breach-notification commitments.
### 7. Data Ownership, Exit, and User Migration
All identity and user-profile data is the property of [AGENCY]. On termination the Contractor shall, within [N days], export all user records — including credentials in a portable form (e.g. password hashes in a documented algorithm) where lawful, and all profile/attribute data — in [open format] at no additional charge, and certify deletion afterward. The Contractor shall support user migration to a successor system without forcing every user to re-register. No proprietary format shall prevent export of user accounts.
### 8. Support and SLAs
Authentication-service availability: [e.g. 99.9%] measured monthly, with credit remedies. Support response: [severity tiers and response times]. The Contractor shall provide implementation, integration guidance, and knowledge transfer sufficient for [AGENCY] staff to operate or migrate the service by end of [period].Score every responsive bid against this rubric. Treat the three gate rows as pass/fail: a failure on any one eliminates the bid regardless of total score.
| Criterion | Weight | Notes |
|---|---|---|
| Authorization (gate) | Pass/fail | FedRAMP/StateRAMP at required level [VERIFY] |
| Accessibility of hosted login (gate) | Pass/fail | Section 508 / WCAG [VERIFY: 2.1 AA] + VPAT |
| User-data portability and exit (gate) | Pass/fail | Open-format export, user migration, no lock-in |
| Cost at projected + 100% volume | 30% | Scored on MAU/seat model, not pilot |
| Protocol and integration fit | 20% | OIDC, SAML, SCIM, MFA completeness |
| Identity proofing / assurance | 15% | IAL/AAL support [VERIFY] for the use case |
| Operational burden | 15% | Staff effort to run, integrate, maintain |
| Support and SLAs | 10% | Availability, response, knowledge transfer |
| Scalability headroom | 10% | Performance and pricing at growth |
Common pitfalls
- Per-MAU pricing exploded at citizen scale. Citizen CIAM looks cheap at pilot volume and ruinous at launch volume, because you pay per monthly active user. Require pricing at projected and +100% MAU before award, as in SOW Section 3, and confirm exactly how the vendor counts a “monthly active user.”
- No user-migration path, so you’re locked in. Your users’ accounts are the lock-in: if the contract has no portable export of credentials and profiles, the vendor owns your leverage at every renewal. SOW Section 7 is non-negotiable; make it a rubric gate.
- One product bought for both citizen and workforce identity. Workforce IdPs price per seat and assume a bounded, trusted population; citizen CIAM prices per MAU and assumes the open internet. Buying one to do both overpays on one side and underserves the other — split the buy.
- Identity-proofing requirement ignored until award. Discovering at award that the platform can’t meet your NIST 800-63 IAL/AAL level [VERIFY] restarts the procurement. Make proofing a defined requirement in SOW Section 4 and a scored line in evaluation.
- Inaccessible hosted login flows. You cannot remediate accessibility on a login UI you don’t control, and an inaccessible login locks citizens out of every downstream service. Require Section 508 / WCAG conformance and a VPAT [VERIFY 508] in SOW Section 5 and make it a pass/fail gate.
- Long contract with no portability. A multi-year term with no exit and migration clause means the renewal is a hostage negotiation. Bound the term and tie it to the portability clause in SOW Section 7.
Procurement notes
Candidate Maryland vehicles depend on the population, the option, and the dollar value, and must be confirmed with your procurement officer.
- Citizen CIAM subscription: [FILL IN: Maryland contract vehicle — e.g. COMMBUYS master contract # / NASPO ValuePoint cloud vehicle].
- Workforce SSO subscription: [FILL IN: Maryland IT software/services vehicle #].
- Self-hosted IdP implementation services: [FILL IN: Maryland IT master services vehicle #].
A shared government identity service may avoid procurement entirely. If [FILL IN: Login.gov / Maryland statewide IdP] is available and your use case is eligible [VERIFY], you may consume it via an interagency agreement or a no-cost/cost-shared arrangement rather than running a solicitation [VERIFY] — confirm eligibility and available assurance levels before assuming this path.
Thresholds decide the route. Below the small-purchase threshold [VERIFY] you may avoid a full solicitation; above it you run an RFP against this runbook’s SOW and rubric [VERIFY]. A typical timeline runs roughly [VERIFY: e.g. 4–8 weeks for a small purchase, 3–6 months for a competitive RFP] — confirm against current Maryland procurement guidance before you commit a date to anyone.
For SOW drafting mechanics beyond this skeleton, see How to write a good SOW.
Maintenance
Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31