Compliance & Privacy · 2026-04-26

FedRAMP Authorization for Identity APIs: The Moderate Baseline and Carrier Signal Processing

By J. W. Bouckaert

This article covers how FedRAMP applies to an identity API that processes carrier signals for U.S. federal customers: how the baseline is chosen, which SP 800-53 controls take the most engineering work, how carrier lookups fit the authorization boundary, and what is changing under the FedRAMP Consolidated Rules for 2026 and FedRAMP 20x.

PasskeyBridge does not hold a FedRAMP authorization. Where this article describes PasskeyBridge, it describes how the platform is built today. That description is not an assessed control set.

Categorization comes first

An agency categorizes its information under FIPS 199, assigning Low, Moderate or High to confidentiality, integrity and availability. Under the FedRAMP Rev5 process, the highest of the three selects the baseline.

An identity API used by a mission system usually takes its categorization from that mission system. Most civilian workloads land at Moderate.

Changes in 2026

The FedRAMP Consolidated Rules for 2026 take effect on July 4, 2026, with enforcement for Rev5 beginning January 1, 2027. The main points:

• 20x replaces Rev5. FedRAMP will stop accepting new Rev5 certifications on June 11, 2027. Existing Rev5 certifications remain active until at least December 31, 2028.
• New terms. "FedRAMP authorization" becomes "FedRAMP Certification", and Low, Moderate and High become Certification Classes A through D.
• New package format. The System Security Plan is replaced by a Certification Package Overview and Security Decision Record, moving from Word and Excel templates to JSON documents or optional OSCAL.
• No more POA&Ms. Plans of Action and Milestones are replaced by a list of Accepted Weaknesses, and vulnerability detection and response goes well beyond monthly scanning.
• FIPS 140 scope. FIPS 140 encryption is expected to protect sensitive data, and providers document their use of it so agencies can judge fit.

Since the FedRAMP Authorization Act of December 2022 and OMB memo M-24-15, the Joint Authorization Board is no longer an authorization path; the FedRAMP Board provides governance. See fedramp.gov/20x for the current status of 20x.

The authorization boundary

The boundary covers the components that store, process or transmit the information being protected (NIST SP 800-37 Rev. 2). Three design choices affect what is inside it for an identity API.

Keep raw identifiers out of storage. PasskeyBridge keys each phone number and other low-entropy identifier with HMAC-SHA-256 under a server-held pepper on arrival and stores only the digest. The raw value is processed in memory for that request and is not written to disk or logs. The receiving component is still inside the boundary, because it processes the value, but storage, backups, analytics and audit hold digests only. See the zero-PII architecture pattern.

Treat carrier APIs as external services. Under SP 800-53 Rev. 5 SA-9 (External System Services), the identity API documents the external service, the data exchanged and the trust relationship. A carrier lookup needs the subscriber number itself, so the documentation has to say the number is sent for that lookup.

Enforce tenant isolation in the database. Row-level security in PostgreSQL, rather than tenant filters in application code, gives an assessor one isolation mechanism to test. This bears on SC-4 (Information in Shared Resources).

Controls that take the most work

AC-2: account management

AC-2 covers account types, approvals, monitoring and removal. A multi-tenant identity API has two planes to satisfy: the provider's own staff and the agency's administrators who provision their own users and credentials. The operator plane should have no implicit right to act inside an agency tenant, and any cross-plane access should go through an approved, audited emergency workflow.

PasskeyBridge gives tenants such a workflow as the Breakglass Protocol: multi-party approval, no self-approval, and a time-bounded session. Its own platform administrators are not separated this way yet: they read across tenants through the admin console without a breakglass session.

AU-12: audit record generation

AU-12 requires audit records for the events defined under AU-2, with enough detail to establish what happened, when, by whom and on what. Useful design choices:

• Hash-chained records, so an edit to any past record breaks the chain.
• Signed checkpoints, so the chain head can be verified independently of the database. PasskeyBridge signs a checkpoint over its audit and event chain heads every five minutes with a hybrid HMAC-SHA-256 and ML-DSA-65 signature. For the trade-offs of signing every row with stateful hash-based signatures, see LMS and XMSS for audit logs.
• Authoritative time for AU-8 (Time Stamps).
• Tenant-scoped access so an agency's auditors see only their own records.

SC-13: cryptographic protection

SC-13 requires the cryptography the system uses to be of the types the organization specifies. In FedRAMP practice that has meant FIPS 140 validated modules, and a validation certificate covers a specific module in a specific operating environment, not an algorithm in general. Under the 2026 rules, providers document where they use FIPS 140 encryption so agencies can decide whether it fits their use.

Post-quantum algorithms complicate this. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) were published in August 2024, and a provider has to check whether the specific module it runs has a CMVP certificate covering them. Pairing a classical signature from a validated module with a post-quantum signature is one way to keep an approved signature in place while adding post-quantum protection. PasskeyBridge runs ML-DSA-65 and ML-DSA-87 in production.

SI-7: software, firmware and information integrity

SI-7 requires detecting unauthorized changes to software, firmware and information. For a SaaS API this is largely a supply-chain question: build provenance such as SLSA, signed SBOMs, and checks that each deployed artifact matches a known build.

PasskeyBridge's supply-chain API checks the structure of tenants' SLSA provenance (the statement's shape, the builder against an allow-list, the artifact and source digests, the presence of a transparency-log entry) and ingests their CycloneDX SBOMs. It does not yet verify the statement's signature or query the transparency log, and its own release pipeline does not produce SLSA provenance yet.

Inheritance from the cloud provider

Running on a FedRAMP-certified infrastructure provider lets a SaaS offering inherit some controls, such as physical and environmental protection, fully, and share others. The exact split is set out in the provider's customer responsibility matrix and depends on which services are used. Most of the control work for an identity API, including account management, audit, cryptography and integrity, stays with the SaaS provider.

Effects and limits of keyed digests

Storing keyed digests instead of raw identifiers reduces what an assessor has to test for data at rest, and it limits the damage of a database breach. It does not make the system PII-free in a legal sense. A keyed digest of a phone number is still linked to that number by anyone holding the key, so it is pseudonymous data, and the agency decides how its privacy requirements apply. Keyed digests reduce the data-at-rest footprint. Privacy obligations still apply.

Practical guidance

1. Start from the agency's categorization and the current Consolidated Rules, and plan for 20x rather than a new Rev5 package if the effort will not reach review before June 11, 2027.
2. Keep raw identifiers out of storage from the start. Retrofitting keyed hashing into a system that already stores raw values is harder.
3. Document carrier and attestation services under SA-9, including what data is sent to each.
4. Design the audit log for integrity: hash chaining, signed checkpoints, authoritative time and tenant-scoped access.
5. Map every cryptographic operation to a module and know which ones have validation certificates.

The FedRAMP rules are changing quickly in 2026. Check fedramp.gov for the current requirements before planning any authorization work.

Start free · Test the API