Compliance & Privacy · 2026-04-26

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

By J. W. Bouckaert

Most discussions of FedRAMP for identity products start with the wrong question. They ask "do we need Moderate or High?" before establishing what the system actually does, what data crosses its trust boundary, and which agency mission it serves. The answer to that question—and the work it implies—falls out of the categorization process, in that order.

This article walks through the specific FedRAMP Moderate controls that apply when an identity API processes carrier signals on behalf of a U.S. federal customer. It explains why a small number of controls (AC-2, AU-12, SC-13, SI-7) account for the bulk of the engineering effort, why a zero-PII architecture collapses the authorization boundary in measurable ways, and what control inheritance from the underlying AWS GovCloud or Azure Government cloud actually does and does not buy you.

The framing throughout is operational. We are not interested in marketing FedRAMP as a logo to put on a slide; we are interested in the architectural decisions that determine whether a 3PAO will sign off on the System Security Plan in eight weeks or eighteen months.

The categorization step comes first

Before any control selection happens, the agency sponsoring the authorization performs a FIPS 199 categorization of the information types the system will process. The categorization assigns each of three security objectives—confidentiality, integrity, availability—a level of Low, Moderate, or High. The high-water mark across the three objectives selects the FedRAMP baseline.

For an identity API that issues authentication assertions and processes carrier signals on behalf of a federal mission system, the categorization typically inherits from the mission system itself. A Treasury non-classified mission system at Moderate produces a Moderate identity-layer requirement. A DHS law-enforcement system at High produces a High requirement. The identity API does not unilaterally select its own baseline.

The practical implication is that an identity vendor pursuing federal customers will, in nearly all cases, need a Moderate authorization first. High authorizations are pursued later, after specific agency demand has materialized, because the incremental control work between Moderate and High is substantial—roughly 100 additional controls, deeper enhancements on existing controls, and stricter inheritance requirements from the underlying cloud.

The authorization boundary is the first architecture decision

NIST SP 800-37 Rev. 2 §2.6 defines the authorization boundary as the set of components that store, process, or transmit the information being protected, plus the supporting infrastructure under direct organizational control. In practice, the boundary diagram is the single most consequential artifact in the entire authorization package. It determines which controls apply, which can be inherited, and which the 3PAO must actively test.

For an identity API, three architectural choices materially shrink the boundary:

1. Process hashed identifiers in place of raw PII. When the system never persists the raw phone number, IMSI, biometric template, or government identifier, those artifacts are never inside the boundary at any point. The identity API receives a hash, queries against a hash, and returns a hash-keyed verification result. The raw data exists transiently in the agency-side client at the moment of hashing and never crosses the API boundary. This is the zero-PII architecture pattern that PasskeyBridge has used since launch, and it has measurable consequences for FedRAMP scope.

2. Treat carrier APIs as external system services. Under SP 800-53 Rev. 5 SA-9, an external service interface is documented and stays outside the boundary. The carrier (Twilio, Vonage, GSMA Open Gateway aggregators) is documented as an external service with a defined data exchange, a trust relationship, and a contractual SLA. Because the data exchanged is a hash—non-attributable under any reasonable threat model—the exchange does not constitute PII transmission and does not pull the carrier into the boundary.

3. Tenant isolation at the database layer, below the application. Row-level security enforced inside PostgreSQL—rather than tenant_id filters in application code—lets the 3PAO test isolation as a single, durable control rather than re-testing every API endpoint. This dramatically simplifies the testing of SC-4 (Information in Shared Resources) and the related access-control family.

The cumulative effect of these three decisions is a boundary diagram in which the vast majority of "identity data" never actually enters the system. The 3PAO assesses what is inside the boundary, and there is materially less inside than there would be in a conventional architecture.

The four controls that dominate the work

Of the ~325 Moderate controls, the bulk of the engineering effort concentrates in four families. Each is briefly summarized here and treated in detail below.

The reason these four dominate—rather than the access-control or contingency-planning families that dominate generic SaaS authorizations—is that identity APIs perform cryptographic operations at very high rates, on behalf of many tenants, with a per-event audit obligation. Every other system in the federal estate writes audit logs; an identity API writes one per authentication assertion, which is one per user request, which scales linearly with traffic.

AC-2: Account management at the tenancy plane

AC-2 requires the organization to identify and select account types, establish conditions for membership, require approvals, monitor use, and notify managers of account events. For a single-tenant SaaS, this is a tractable problem: there is one tenant, one role hierarchy, and one set of provisioning workflows.

For a multi-tenant identity API serving federal customers, AC-2 doubles. There is the operator tenancy plane—the platform's own staff with access to platform infrastructure—and the agency tenancy plane, where the agency's administrators provision their own users, roles, and API credentials. AC-2 control enhancements (AC-2(1) through AC-2(13) at Moderate) require both planes to satisfy: automated account management, automated removal/disable, role-based scheme, automated audit, dynamic privilege management, account monitoring, account inactivity logout.

The PasskeyBridge implementation separates these planes architecturally. Operator accounts live in a dedicated admin tenancy with its own MFA policy, session timeouts, and audit stream. Agency accounts live in agency-scoped tenants with row-level isolation. Neither plane can read the other's data, and the operator plane has no implicit privilege to act as an agency user—any cross-plane action requires an explicit, audited break-glass workflow under the Breakglass Protocol controls.

AU-12: Audit record generation at scale

AU-12 requires the system to generate audit records for the events specified by AU-2, with sufficient information to establish what occurred, when, by whom, and on what. For an identity API at production rates—tens of millions of authentication assertions per day across the agency tenant base—this is the highest-volume control in the system.

The architectural decisions that make AU-12 tractable at FedRAMP scale:

• Per-event cryptographic signature so the integrity of the audit record is verifiable independently of the storage medium. We use stateful hash-based signatures for this because the workload (append-only, single-writer, predictable cadence) matches LMS's preconditions exactly.
• Hash-chained log entries so any tampering with a historical row is detectable through the integrity of the chain, not just the integrity of the individual signature.
• Stratum-2 NTP-synchronized timestamps sourced from a hardened time service so that the AU-8 (Time Stamps) requirement of authoritative time is satisfied without relying on system clock drift.
• Tenant-isolated audit streams so an agency's auditors can be granted access to their own audit data without exposure to any other tenant's records, satisfying the AU-9(4) requirement to protect audit information from unauthorized access.

SC-13: Cryptographic protection and FIPS 140-3

SC-13 requires that cryptographic mechanisms used to protect organizational information be FIPS 140-2 or FIPS 140-3 validated. The "validated" word matters: it does not mean "FIPS-compliant algorithm." It means a Cryptographic Module Validation Program (CMVP) certificate covers the specific module performing the operation, with a specific operating environment.

The chart below summarizes the typical FIPS validation status of the cryptographic primitives used in an identity API as of 2026:

The practical implication is that a Moderate-baseline identity API in 2026 must perform classical cryptography (AES, ECDSA, HMAC) inside a validated module today, while staging post-quantum primitives behind a feature flag that is enabled per-tenant once their CMVP certificates land. The hybrid signature scheme we use—dual-signing with ML-DSA and Ed25519—is the architectural pattern that satisfies SC-13 today (the Ed25519 signature is in the validated path) while making the post-quantum migration a configuration change rather than a re-engineering effort.

SI-7: Integrity from source to production

SI-7 requires the system to detect unauthorized changes to software, firmware, and information. For a modern SaaS API, this is a supply-chain question: every npm package, every container layer, every Deno module that ends up in production must have an attestable provenance chain.

The PasskeyBridge approach uses SLSA Build Level 3 provenance for every artifact, signed SBOMs (CycloneDX) for every release, and a continuous-monitoring scan that flags any production binary whose digest is not present in the signed manifest. The 3PAO can verify the entire chain from a single API call: given a deployed binary's digest, return the build provenance, the source commit, and the SBOM. SI-7 then becomes a single, auditable control surface rather than a sprawling collection of point-in-time scans.

Inheritance from the underlying cloud

A common misconception is that running on AWS GovCloud or Azure Government inherits "FedRAMP" wholesale. It does not. What gets inherited is a specific, enumerated subset of controls, documented in the cloud provider's Customer Responsibility Matrix.

A representative split for a Moderate-baseline identity API on a FedRAMP-authorized IaaS:

The full Moderate baseline contains additional families (Awareness and Training, Contingency Planning, Maintenance, Media Protection, Personnel Security, Risk Assessment, Security Assessment and Authorization, System and Information Integrity, System and Services Acquisition, Planning, Program Management) that follow similar inheritance ratios. Across all 325 Moderate controls, a typical SaaS identity API inherits 60 to 80 controls fully and partially shares another 40 to 60. The remaining 200+ are direct provider responsibility.

The lesson is that the underlying cloud is necessary but not sufficient. The engineering work of FedRAMP is the implementation, documentation, and continuous monitoring of the 200+ controls that the provider owns directly.

Zero-PII and the control set

The architectural payoff of zero-PII processing is most visible in three control areas:

Privacy overlay scoping. FedRAMP Privacy controls are an additional overlay applied when the system processes PII. When the system processes only hashed identifiers, the agency typically confirms in the categorization step that no PII is processed by the system, and the overlay is removed from scope. This eliminates roughly 25 controls and the entire Privacy Threshold Analysis exercise.

MP (Media Protection) controls. Media containing PII triggers a more stringent set of MP controls—physical destruction requirements, transport encryption, sanitization standards. Hashed-only architectures push the entire MP family toward inheritance from the underlying cloud's standard data-handling controls.

SI-12 (Information Management and Retention). Retention policies apply differently to PII versus non-PII. Hashed identifiers are subject to operational retention only and can be aggressively rotated under a Reg S-ID equivalent compliance posture without triggering data-disposal regulations.

The cumulative effect is that an architecture which never persists raw PII can land on a noticeably smaller authorization boundary—our internal estimate, validated against two recent agency advisory engagements, is a reduction of roughly 15% in active control surface and a similar reduction in 3PAO testing scope. The dollars and weeks saved are real; the security improvement is independently real.

The authorization process

The FedRAMP authorization workflow has well-documented phases. The summary below applies to the Agency ATO path, which is the most common path in 2026 for identity vendors entering federal markets.

Total elapsed time from kickoff to ATO is typically 6 to 12 months, with documentation and 3PAO assessment running in partial parallel for experienced providers. Industry-reported cost ranges, summarized against current FedRAMP program guidance, cluster between $250K and $750K for documentation and 3PAO fees, exclusive of any engineering rework triggered by gap findings. The single biggest predictor of timeline overrun is the volume of gap findings in the readiness assessment, which is itself a function of how cleanly the architecture was designed against the control baseline before authorization work began.

The 2026 picture: FedRAMP 20x and continuous ATO

The FedRAMP 20x program, in pilot during 2026, targets a substantial reduction in authorization timelines through automated continuous monitoring evidence and machine-readable control attestations. The premise is that providers who can stream control evidence from their production environment in a standardized format—rather than producing PDFs at a quarterly cadence—can shift the assessment model from periodic to continuous.

For identity APIs specifically, this is a natural fit. Every control we have discussed (AC-2, AU-12, SC-13, SI-7) is already instrumented in real time inside any well-engineered platform. The audit-log signature chain is the SI-7 evidence; the per-tenant role-management events are the AC-2 evidence; the FIPS module-status calls are the SC-13 evidence. A platform that already does these things does not need a quarterly evidence-collection sprint; it needs an OSCAL-formatted streaming endpoint that the 3PAO can subscribe to.

PasskeyBridge has built this endpoint as part of our continuous monitoring posture, and we expect the FedRAMP 20x evolution to favor identity providers who treat compliance evidence as a product surface rather than a periodic chore.

Practical guidance for identity vendors

If you are an identity vendor evaluating the FedRAMP path in 2026, the architectural prerequisites are less negotiable than the policy work. You will likely need to:

1. Operate inside a FedRAMP-authorized cloud boundary (AWS GovCloud, Azure Government, or one of the smaller authorized providers). This is a non-negotiable starting point.
2. Pursue a zero-PII architecture for any identity signal that touches the system. The boundary collapse is significant, and retrofitting hashing into a system that already persists raw identifiers is materially harder than building it that way from day one.
3. Use FIPS 140-3 validated cryptographic modules for every cryptographic operation, with a clear plan for the post-quantum migration once ML-DSA and SLH-DSA validations land in 2026.
4. Build the audit log as a first-class architectural concern—per-event signature, hash-chained, NTP-synchronized, tenant-isolated. Retrofitting AU-12 onto a logging system that was designed for debugging is among the most painful engineering exercises in the FedRAMP path.
5. Treat external service integrations (carrier APIs, attestation services) as SA-9 boundary interfaces and document them accordingly. Hashed query patterns make this clean; raw-data exchanges make it messy.

The identity providers that complete a Moderate authorization on the median timeline are the ones who treated the control baseline as a design constraint from the beginning rather than a documentation exercise at the end. The four control families above—AC-2, AU-12, SC-13, SI-7—are the ones where that distinction shows up first.

Start free · Test the API