FedRAMP Machine-Readable IAL3 Evidence: OSCAL, Signed APIs, and Data Minimization

FedRAMP published its Consolidated Rules for 2026 on June 24, 2026, beginning a transition from Word- and spreadsheet-centered packages toward schema-valid JSON artifacts, Security Decision Records (SDRs), trust-center distribution, and programmatic access. Optional early adoption began July 4, 2026, and the rules generally become mandatory January 1, 2027, subject to the effective dates and grace periods for each ruleset. FedRAMP will stop accepting applications for new Rev5 certifications after June 11, 2027. The official timeline should be treated as the source of truth.

This is broader than an OSCAL mandate. FedRAMP now publishes its own lightweight JSON Schemas for submission artifacts and requires valid JSON when a rule identifies a corresponding schema. OSCAL remains a useful standardized source and exchange format — and is optional in some parts of the new process — but it is not the one universal format for every FedRAMP deliverable.

Identity proofing makes this transition unusually sensitive. A customer or assessor needs structured evidence that an identity decision occurred, at what assurance level, and under what process. They generally do not need identity-document images, biometric samples, or session media copied into a broadly shared certification package. The final Certification Data Sharing rules reinforce this design constraint: providers should not include employee PII in certification data and should anticipate a breach of that data’s confidentiality.

Trust Swiftly’s approach separates reusable control documentation, signed decision evidence, and raw proofing artifacts. The result is machine-validatable evidence with a deliberately narrow disclosure surface — while preserving controlled access to the underlying artifacts when an assessment genuinely requires them.

What FedRAMP Requires — and Where OSCAL Fits

The Open Security Controls Assessment Language (OSCAL) is a NIST-maintained family of JSON, YAML, and XML models for control catalogs, profiles, component definitions, System Security Plans, assessment plans and results, and POA&Ms. It lets tools validate, compare, and reuse structured control information instead of repeatedly translating the same implementation into prose.

The 2026 rules introduce a related but distinct FedRAMP structure. A traditional SSP is replaced in the new package by a persistently maintained Security Decision Record. The package also includes a Certification Package Overview and, for Classes B–D, a real or example Ongoing Certification Report. When FedRAMP publishes a schema for one of these artifacts, the corresponding JSON must validate against it.

That makes OSCAL valuable as reusable source material rather than a promise of one-click authorization:

Public OSCAL schemas and catalogs are freely available. Customer-specific certification data has a more nuanced distribution model: the final rules require a public subset in human-readable and JSON formats, while broader certification data is shared with necessary parties through a FedRAMP-compatible trust center. Trust centers must provide documented programmatic access and log access to certification data. A package is therefore neither automatically public nor confined to a single private document repository.

For Rev5 Class D, providers must keep the certification package complete and current at least once every six months. The final rules describe this as a maximum maintenance interval, not a reason to wait six months after a material change. Machine-readable identity evidence is most useful when it is generated continuously and then summarized into the required package and reporting cadence.

Why IAL3 Evidence Needs a Separate Disclosure Layer

NIST SP 800-63A-4 defines IAL3 as on-site attended identity proofing. The proofing agent may be co-located with the applicant or attend remotely through a CSP-controlled kiosk or device. IAL3 requires collection and retention of a biometric sample, validation of qualifying identity evidence, and an attended initial authenticator-binding process.

Video recording is not an inherent IAL3 requirement. A CSP may record a session for fraud prevention or prosecution, but if it does, NIST requires prior notice and consent plus a published retention schedule and deletion process. Whether recorded or not, an IAL3 implementation handles sensitive material such as identity attributes, document data, biometrics, agent observations, and device or session telemetry.

Copying that material into certification data creates unnecessary exposure. A machine-readable package may be processed by customer engineers, automated pipelines, assessors, and agency systems, and historical snapshots must be retained for the duration of the certification. Even an internal Git workflow makes accidental disclosure difficult to reverse because objects and prior versions can be replicated across clones, caches, and backups.

The safer objective is data minimization, not an absolute claim of “zero PII.” An opaque subject UUID reveals less than a name or document number, but it can still be linkable to a person in the customer’s or assessor’s environment. Exact timestamps, supervising-agent identifiers, and report references can also become identifying when combined with other records. These fields still require access control, retention rules, and a documented privacy risk assessment.

The machine-readable decision layer should therefore exclude direct identity attributes and raw proofing artifacts by construction, use opaque correlation identifiers, and disclose only what a relying organization needs to evaluate the control.

A Three-Layer Evidence Architecture

The architecture separates information according to audience, sensitivity, and what it can actually prove.

Layer 1 — Reusable OSCAL control documentation

Trust Swiftly’s documentation layer uses an OSCAL 1.2.2 component definition mapped to IA-12 and applicable enhancements, together with a customer responsibility matrix. The generic component material describes the service and evidence API without customer configuration or per-user records.

An OSCAL-aware GRC tool may import this material; other teams may copy and tailor the applicable content into their own SDR or SSP workflow. Tool support varies, so a component definition should be described as reusable source material rather than a universal direct-import mechanism. It must validate against the official OSCAL schema, resolve every control against an immutable catalog release, and carry clear version and release metadata.

Layer 2 — Signed, data-minimized decision evidence

The authenticated Identity Evidence API returns a machine-readable snapshot of Trust Swiftly’s current identity decision. Its structure follows the OpenID Identity Assurance verified_claims pattern and includes an opaque subject UUID, the claimed assurance level, proofing type, decision and revocation fields, decision and issuance timestamps, a supervising-agent identifier when available, and a report reference.

The identity-attributes object is structurally empty (maxProperties: 0). Names, contact details, document numbers, biometrics, precise location, and device-attestation details remain outside the response. Because the remaining correlation fields may still be linkable, the API is token-scoped, rate-limited, and returned with no-store caching semantics.

Each response is signed as a compact JWS using ES384 over a canonicalized payload. ES384 uses ECDSA P-384, an algorithm permitted by FIPS 186-5; that algorithm choice alone does not establish that every deployment component is a FIPS 140-validated cryptographic module. Verifiers use the API’s JWKS endpoint, including retained retired public keys, to validate historical signatures across key rotations. A versioned JSON Schema lets clients validate the response structure separately from its signature.

The signature establishes that the record came from the holder of the signing key and has not changed. The record remains an assertion of the current provider decision. Assessment of the procedure, evidence quality, and decision correctness requires the control documentation and, where necessary, underlying artifacts.

Layer 3 — Controlled, hash-bound artifacts

Detailed identity reports, recordings when used, and capture artifacts remain in controlled storage rather than the certification package. Trust Swiftly binds eligible secure reports to immutable receipts:

• The report is hashed with SHA-512 at generation.
• A receipt records the report UUID, generation time, file hash, and previous-record hash.
• The receipt is written to versioned object storage under a locked retention policy.
• The receipt contains an RFC 3161 timestamp token and validation material from an external timestamping authority.

The current verification endpoint validates an individual current-format report against its database record and immutable receipt, then validates the RFC 3161 message imprint, timestamp signature, certificate purpose, and trusted certificate chain. The previous-record hash is bound into the current receipt, but the v1 contract verifies each report and receipt independently.

An Honest Automated Validation Path for Assessors

A signed API can reduce unnecessary access to raw evidence, but it should not be presented as a substitute for substantive assessment. A defensible workflow is graduated:

1. Define the population from an authoritative customer source. Start with the IAM group, HR roster, or other in-scope population — not the vendor dashboard — so missing records remain visible.
2. Select an assessor-controlled sample. The assessor chooses subjects from that population and receives a narrowly scoped evidence-read token.
3. Validate each signed assertion. Verify the compact JWS against the matching JWKS key, compare the embedded payload with the returned object, validate the JSON Schema, and evaluate the asserted decision, IAL, process type, status, and timestamps.
4. Validate eligible report integrity. If the assessor holds the report or has obtained its digest through an independently trusted path, submit its SHA-512 digest to the verification endpoint. A signed verified result confirms that the digest matches the current database record and immutable receipt and that the timestamp token validates.
5. Inspect underlying evidence where required. Hash validation proves integrity of a known file; it does not reveal whether that file documents a compliant proofing ceremony. The assessor reviews controlled artifacts for the sample size and clauses required by the assessment methodology.
6. Reconcile the full population. Compare in-scope subjects with current signed decisions to detect missing, inconclusive, or disallowed records without opening every identity artifact.

This distinction matters. Eligible current-format records can be checked mechanically for schema validity, signature integrity, status, and receipt integrity. Human reviewers can then focus raw-evidence access on the sample needed to validate process effectiveness. That provides broader automated coverage without claiming that cryptography alone proves IAL3 conformity.

IAL3 Is One Decision in the Access-Approval Chain

IAL3 answers an identity question: how strongly has this applicant's real-world identity been established? It does not answer whether that person is an active employee or contractor, needs access to a particular system, or should receive a privileged role. Trust Swiftly typically makes the proofing decision; the customer remains the authority for workforce status and access to its authorization boundary.

That distinction is especially important for privileged access. The final FedRAMP Rev5 Class D baseline includes AC-2 Account Management, AC-2 (07) Privileged User Accounts, AC-5 Separation of Duties, and AC-6 Least Privilege. These controls support documented account approval, additional scrutiny for privileged roles, separated duties, and limited privileges. They do not prescribe one universal HR-and-manager approval sequence. Each organization must define the approvers and prerequisites appropriate to its boundary and risk.

A common workflow separates the following decisions:

Some organizations implement these stages in an identity-governance product such as SailPoint; others use an IT service-management or privileged-access workflow. The product matters less than the evidence contract. Each stage should emit an immutable event containing an opaque subject and request identifier, the decision, reviewer role, timestamp, policy version, reason or exception code, and a source-system reference. Names, portraits, and other direct identifiers do not need to be copied into the assessor-facing event stream.

For a privileged role, the policy engine can require an acceptable current IAL3 result plus every customer approval before provisioning. It should reject self-approval where separation of duties applies, prevent Trust Swiftly's proofing result from being treated as the final access authorization, expire abandoned requests, and preserve any emergency or exception path for later review.

Use workforce photos as controlled corroboration

An up-to-date portrait already maintained by an employer's badge or workforce system can be useful corroborating evidence. It may help an authorized HR reviewer investigate a discrepancy, help a manager flag that the applicant does not appear to be the expected employee, or serve as a customer-controlled reference for a permitted one-to-one comparison. NIST's identity evidence examples recognize corporate photo ID as potential identity evidence, but its strength depends on how the organization issued, validated, and protects it. A badge photo is not automatically an authoritative biometric source or sufficient IAL3 evidence.

This should not become a blanket instruction to create or retain a portrait of every worker solely for assessment. Collection, permissible use, freshness, retention, access, and deletion should follow the organization's employment, privacy, and biometric policies. If software compares facial images, the portrait and derived template are biometric data; NIST requires clear disclosure of biometric uses, explicit informed consent, protection, and a removal process for biometrics used in proofing. The NIST visual-comparison requirements also require trained and assessed proofing personnel when visual facial comparison is part of the proofing process.

Keep the portrait in the authoritative HR or badge repository and expose only the minimum review result: the source type, when it was last confirmed current, whether the comparison passed or was escalated, the reviewer role, and an opaque evidence reference. A manager's familiarity with an employee is a valuable fraud signal, but it should trigger review rather than replace validated identity evidence, a trained proofing agent, or the formal access approver.

This creates multiple independent attestations instead of one all-powerful reviewer: the CSP establishes identity, HR confirms the workforce relationship, the manager or owner confirms business need, and the account authority approves access. The extra approvals add assurance only when their responsibilities and source data are genuinely distinct.

Lifecycle Queries Worth Automating

Once decisions are queryable, several high-value control checks become joins rather than document searches:

• Access before required proofing. Where policy requires proofing before a privilege is activated, compare the access-grant timestamp with the proofing decision timestamp.
• Privileged access without a complete approval chain. Join the IAL3 decision to the IGA, IAM, or PAM request and verify that every policy-required approval preceded activation. Treat missing, expired, denied, or out-of-order decisions as exceptions.
• Approval and separation-of-duties conflicts. Detect self-approval, one person acting in incompatible approval roles, privilege owners approving their own access, and provisioning performed outside the governed workflow.
• Authenticator binding that does not match the selected identity profile. IAL and AAL address different risks. An AAL3-capable account does not universally require IAL3, and possession of a YubiKey does not by itself establish AAL3. Where the organization's documented profile requires both IAL3 and AAL3, trace the qualifying authenticator to the required proofing and binding events. NIST's digital identity risk-management process governs that selection.
• Downstream access after an adverse identity decision. Reconcile banned, inconclusive, or otherwise disallowed decisions against active accounts and privileges according to the customer's policy.
• Workforce or corroborating-source mismatch. Compare active access with authoritative HR status and, when the organization uses a workforce portrait as a secondary check, flag stale source records or unresolved comparison escalations without exporting the portrait.
• Missing or policy-stale records. Subtract subjects with a current acceptable decision from the authoritative in-scope population. Apply organization- or agency-defined reproofing and recertification events rather than implying that NIST sets one universal IAL3 expiration date.

Signed webhooks can gate downstream workflows on a completed decision, SCIM 2.0 can support account lifecycle integration, and SIEM or audit-log exports can place proofing failures and status changes in the customer’s monitoring pipeline. These integrations support the customer’s control implementation; they do not transfer ownership of access decisions or authenticator lifecycle to the proofing vendor.

Implementation Checklist

1. Start from the final FedRAMP artifact requirements. Build the required Certification Package Overview, SDR, reports, and related JSON around the current FedRAMP rules and schemas. Use OSCAL where it provides reusable control information or supported interchange.
2. Minimize data structurally. Exclude direct identifiers and raw evidence from broadly shared records, constrain free-form fields, use opaque identifiers, and document residual linkability in a privacy risk assessment.
3. Validate deterministically. Validate FedRAMP JSON and OSCAL artifacts in CI, resolve control IDs, check local and published links, and fail builds on stale version metadata or malformed evidence contracts.
4. Pin catalogs and schemas. Reference immutable official releases and upgrade deliberately so a moving catalog cannot silently change the meaning of an implementation statement.
5. Sign assertions and document key lifecycle. Publish verification keys, retain retired public keys for the evidence retention period, fail closed when signing is unavailable, and distinguish an approved algorithm from FIPS 140 module validation.
6. State the integrity boundary precisely. Say whether a verifier checks one report, a receipt, a full historical chain, or the substantive report contents. Do not use those claims interchangeably.
7. Separate proofing from authentication decisions. The relying organization selects IAL and AAL for each user group and remains responsible for authenticator binding, recovery, and access policy.
8. Model access approval separately from proofing. Make the signed IAL3 decision one prerequisite in the customer's IGA, IAM, or PAM policy. Preserve HR, manager or owner, system-authority, separation-of-duties, exception, and provisioning events without copying their underlying PII into the certification stream.
9. Publish a complete vendor package. Release the component definition, responsibility matrix and its schema, evidence JSON Schema, OpenAPI document, release notes, and checksums through a stable customer or trust-center location.
10. Follow the final transition dates. For Class D, keep the package current at least every six months, preserve required historical snapshots, and monitor the Consolidated Rules changelog for schema and rule updates.

What Trust Swiftly Provides

Trust Swiftly supports attended IAL3 workflows using controlled hardware, trained-agent sessions, detailed identity reports, and customer-visible evidence. The machine-readable layer adds a versioned OSCAL component definition and responsibility matrix, a signed decision API, published verification keys and schema, per-report WORM receipt verification, RFC 3161 timestamp validation, and integration paths for audit and lifecycle automation.

These artifacts can accelerate a customer’s FedRAMP work, but they are not themselves a FedRAMP certification, an independent IAL conformity determination, or proof that the customer has selected and implemented the correct IAL/AAL profile. Customers should request the current OSCAL package, API contract, security attestations and certificates, independent assessment scope, and retention documentation as part of due diligence.

Where a customer permits IAL2 for a separate lower-risk use case, IAL2 and IAL3 workflows can operate in parallel. IAL2 should never be represented as a temporary substitute for access that the customer’s documented policy requires to be IAL3.

Preparing machine-readable FedRAMP evidence or an IAL3 rollout? Contact Trust Swiftly to review the OSCAL source material, evidence API, privacy boundary, and assessor validation path — or begin with the IAL3 audit evidence checklist and Federal Identity Proofing.