Our earlier article made the case for running NIST SP 800-63-4 IAL3 identity proofing as a continuous FedRAMP 20x indicator: FedRAMP maps KSI-IAM-AAM to IA-12 Identity Proofing, and account automation is not secure if nobody verified the people behind the accounts. That piece answered why; this one answers how, for the class where the bar is highest. The companion implementation guide holds the code, queries, and Security Decision Record excerpt.
The FedRAMP Consolidated Rules for 2026 put a number on automation. Under FRC-CSX-VVK, Class C providers must persistently verify and validate each Key Security Indicator with at least two automated methods; Class D providers must use at least four. Under FRC-CSX-MOT, Class D must supply historical metrics from persistent validation covering at least the past 18 months, with an exception for initial certification: a provider without the history may proceed with the mechanisms in place and an agreement to accumulate it. Class D itself is a Phase 4 pilot targeted for FY27 Q1 to Q2, with its metric specifics deferred to that pilot; we covered what we expect Class D to ask of identity separately. History is the one input that cannot be accelerated, and a provider that starts recording now arrives with evidence instead of a promise.
A word on why we wrote it. Trust Swiftly is pursuing FedRAMP certification itself, and when we worked through the Key Security Indicators we sorted them by how hard they would be to validate honestly. Some are easy. The identity and access ones are not: implementing them properly is a lot of work, and Class D demands exactly that work. Since 20x does not yet define what Class D validation must look like, this is our proposed design, published so other providers can build on it or argue with it.
Two scoping notes. KSI-IAM-AAM covers the lifecycle and privileges of every account, role, and group: provisioning, deprovisioning, role and group changes, privilege changes, and exceptions, as well as identity proofing. The five methods here validate the identity-proofing measure within that indicator, not the whole indicator; the other measures need their own methods. And nothing in FedRAMP's rules requires that the four methods read different things; that diversity is our recommendation for making the sufficiency case under SDR-CSX-KSI.
FedRAMP 20x Class D and IAL3, in brief:
- The rule: FRC-CSX-VVK requires at least four automated methods per KSI at Class D. FRC-CSX-MOT requires 18 months of persistent validation history. SDR-CSX-KSI requires the Security Decision Record to explain each measure, its cycle, and verification that the automation is accurate and sufficient.
- The risk: Four checks that all read an
ial=3attribute from the directory may not convincingly demonstrate four sufficiently distinct methods to an assessor, because a directory attribute is a label, not a proofing event.- The recommendation: Diversify what each method reads: the proofing ledger, live enforcement configuration, enforcement-point behavior, the session log stream, and the authenticator presented at login. Check state transitions in real time and sweep daily. Document the dependencies the methods still share.
- The population: Privileged and vendor personnel are the floor. For Class D we recommend everyone with access into the boundary.
What the Rule Asks For, and What It Does Not
FRC-CSX-VVK is short: providers seeking Class D "MUST implement automated methods to persistently verify and validate the accuracy and completeness of Key Security Indicators with at least 4 automated methods for each Key Security Indicator." Four words in it have defined meanings.
Verification and validation are different. FedRAMP defines verification as confirmation through objective evidence that specified practices have been fulfilled, and validation as confirmation that implemented capabilities support the expected security outcomes. Confirming the IAL3 rule is present in a policy is verification; attempting access without proofing and confirming it fails is validation. A set that does only one is weaker than a set that does both.
Accuracy and completeness are properties of the measurement. Is the number you report correct, and does it cover every account it should? At least one method needs to test the denominator, not just the enforcement.
Persistently does not mean continuously. FRD-PER means repeated in cycles that are intentional, understood, and documented, with the status always known; its note says persistent processes may not occur continuously or even regularly. SDR-CSX-KSI asks for the cycle of every persistent measure. A daily sweep with event-driven triggers is fully persistent.
Distinctness is not defined. The rule counts methods; it does not say what makes two different and imposes no source-of-truth test. What SDR-CSX-KSI does impose is verification "that the automation in place is accurate and sufficient," which an independent assessor evaluates. Our recommendation is to be able to answer the question an assessor is likely to ask: if this one component were wrong, would every method still pass? We also recommend emitting what FedRAMP defines as deterministic telemetry, reproducible observations from an authoritative source, because that is what an assessor can re-derive.
The Design Risk: Validating the Label Instead of the Proofing
A common first draft of IAL3 validation looks like this: a Terraform check that the access rule requires the IAL3 group, a directory query that every active user has identityAssuranceLevel = IAL3, a gateway check for the IAL3 claim in the token, and a SIEM query for logins where the claim was absent. Four tools, four scripts, one fact. The attribute is set at provisioning; the group derives from the attribute; the claim from the group; the log field from the claim. If an administrator sets the attribute by hand on an unproofed account, all four report a pass. Whether an assessor counts that as four methods is their call; we would not want to argue it.
The attribute is a label. What it labels is a proofing event: an on-site attended session in which evidence was validated and verified, a biometric was collected, an authenticator was bound, and, in our implementation, automated presentation attack detection ran. That event produces a record that exists independently of anything the directory says, and at least some of the methods should reconcile against it.
Where the record lives
The pattern we recommend, and the one customers on our minimal-retention configuration run, is split custody. At the end of an attended session the proofing provider produces an audit package: outcome, session metadata, evidence and PAD results, operator actions, chain-of-custody records, the retained biometric sample, and the identifier of the authenticator bound in the session. The package goes to the cloud service provider's own evidence store. The provider then deletes the underlying records and retains a ledger entry: the customer's reference ID, a hash of the package, assurance level, completion timestamp, and a status that can move to revoked, served by a real-time API and pushed by webhook.
Three things need saying precisely about what that provides.
What the hash proves. That the package in your store is byte-for-byte what the provider hashed at delivery, and that neither copy has changed since. It does not prove an attended session took place; a provider that produces both the package and the ledger entry could produce both for a session that never happened, and provider signatures or transparency logs prove provenance and immutability, not that the event occurred. If a malicious provider is in your risk model, what addresses it is an independent witness at the session, applicant confirmation over a channel you control (the new hire confirms attendance through the corporate account HR established), or session telemetry the provider does not control, such as a kiosk on your premises with your own logging. Decide whether that threat is in scope and say so in the shared-responsibility matrix.
Workforce-identity reconciliation. The provider verifies that a real person with valid evidence sat in front of the sensors and bound an authenticator. It does not know whether that person is the one your organization expected to start on Monday; the hiring manager, HR partner, or vendor sponsor does. The practice that closes the gap is an approval step in the identity governance or ticketing workflow (ServiceNow, SailPoint, whatever runs joiner-mover-leaver) in which that person reviews the session outcome against the HR record of the expected worker, compares the session capture to a badging headshot where one exists, and attests to the match before the identity joins any boundary group. Be clear about what this proves: that the identity in the provider's evidence is the expected worker, not that the provider conducted the session. Its value is elsewhere. The most common finding it produces is drift between systems of record: a surname changed at marriage and updated with the DMV but not HR, an address that moved with the person but not payroll. Treat each mismatch as a reconciliation task, fix the stale system, record which one was wrong, and let Method 1 require the attestation. None of this is a NIST requirement; it is a best practice that makes the provider's evidence mean what you need it to mean.
What the ledger contains, and who retains the biometric. The ledger omits identity documents, biometrics, and direct identifiers; it still holds a subject reference, timestamps, and status, which may be linkable personal information under your privacy assessment. Separately, SP 800-63A-4 requires the credential service provider, in NIST's sense of the entity operating the subscriber account, to retain a biometric sample at IAL3, and SP 800-63B-4 relies on it for AAL3 account recovery. In split custody the retained sample is in the package, which satisfies the requirement only if the package's custodian is the credential service provider or acts for it under a documented split, keeps the sample for the account's lifetime, and can produce it for a recovery comparison. Write that into the practice statement.
For reconciliation to work, the two halves need to carry the following.
| Field | Held in | Why it matters |
|---|---|---|
| Subject reference ID mapping to your directory | Ledger, package | The join key. |
| Package hash | Ledger | Tamper evidence after delivery. |
| Assurance level | Ledger, package | Distinguishes IAL3 from IAL2 on the same platform. |
| Completion timestamp | Ledger, package | Lets you assert proofing preceded the access grant. |
| Status and revocation timestamp | Ledger | A record found fraudulent later must invalidate access. |
| Initial bound authenticator identifier | Ledger, package | Anchors the account's authenticator record to the attended session. |
| Evidence, PAD, operator, and biometric records | Package only | Assessor sampling, and AAL3 recovery. Never leaves your store. |
| Sponsor attestation: who confirmed the proofed person is the expected worker, when, against which HR record | Your IGA or ticketing system only | The one input the provider cannot produce, and where name and address drift gets caught. |
If your provider retains full records and exposes no hash, the methods below still work with the provider's record as the anchor; you lose tamper evidence in your own custody and the retention minimization.
On Cadence
A proofing record is immutable once written; polling it hourly produces 24 identical results a day, and a canary every 15 minutes against a policy that changes twice a quarter is the same mistake. What needs to be fast is the check at a state transition: access granted, record revoked, policy deployed. Those run synchronously and stop a bad session. Everything else is a daily sweep that catches drift and produces the day's datapoint, which is what SDR-CSX-KMT collects. Real time where state changes, daily where it does not.
Five Diversified Methods
The rule says at least four. We describe five: the fifth turns proofing from a provisioning-time check into a per-session one, and five leaves margin so one method can be rebuilt without dropping below the floor.
| Method | What it reads | Question it answers | Cycle | Type |
|---|---|---|---|---|
| 1. Ledger reconciliation | Provider ledger via API, plus the package in your store | Does every boundary identity have a valid IAL3 record that preceded its grant, hashes correctly, and accounts for every credential the directory holds? | On grant and reinstatement; daily sweep | Verification (accuracy) |
| 2. Enforcement configuration | Live IdP and gateway policy via API, diffed against IaC state | Is every effective access rule deployed as intended right now? | On deploy; daily | Verification (drift) |
| 3. Behavioral probing | Enforcement-point runtime behavior | Does the boundary refuse an unproofed but otherwise valid identity? | Daily negative probe; attended positive probe on change | Validation (outcome) |
| 4. Session reconciliation | Gateway, IdP, and cloud audit logs, joined to webhook-fed status | Did every session that occurred, on every ingested path, map to a record valid at that moment? | Daily batch; streaming alert | Validation (completeness) |
| 5. Bound-authenticator posture | The credential and the transaction at authentication, against the account's authenticator record | Did this key enter the account through a permitted binding path, and did this login actually achieve AAL3? | Every authentication; daily datapoint from the decision log | Validation (per session) |
Method 1: Ledger Reconciliation
For every identity with access into the boundary, enumerated from every system that can confer it (IdP groups, cloud IAM roles, PAM vaults, break-glass holders, vendor accounts), the reconciler locates the audit package, hashes it, fetches the ledger entry, and asserts: package present, hash matches, IAL3, status valid, completion before the first access grant, sponsor attestation present and resolved, and every credential the directory holds accounted for by a permitted binding path. That last assertion needs the lifecycle stated correctly; SP 800-63-4 recognizes three ways a credential legitimately enters a proofed account:
- Initial binding during the attended session, under SP 800-63A. The provider records it; the ledger corroborates it.
- Adding another authenticator afterward, under SP 800-63B-4: the subscriber authenticates at the AAL the new authenticator will be used at and the credential service provider sends an independent notification. No biometric comparison and no proofing-provider involvement are required. The identity provider's own authenticator record, which 63B-4 requires with dates and times of every binding, is the evidence.
- Account recovery after losing every AAL3 authenticator, under 63B-4's recovery rules: for an IAL3-proofed account, a biometric comparison against the sample retained from the attended session, then a new binding.
Routing every binding through the proofing provider is a defensible product design, and it is what our workflow does for the first and third paths; NIST does not require it for the second. The reconciler's check is that each credential's binding event is one of the three, with the evidence each leaves. A credential with none, typically a help-desk registration that skipped both the AAL3 authentication and the recovery comparison, is the finding. Method 1 gates every grant and reinstatement synchronously and sweeps the population daily. It cannot see whether the gateway is enforcing anything.
Method 2: Enforcement Configuration Assurance
Read the live policy from the identity provider and every enforcement point through their management APIs, evaluate it with a policy engine, and diff it against infrastructure-as-code state in the same run. A policy-as-code gate in CI runs when someone commits and evaluates intended state; the failure that matters is a console change that never went through the pipeline. Keep the CI gate as a preventive control; only the scheduled run against live state is a persistent method.
The evaluation must cover every effective access path, not find one good rule. An application with one allow policy that requires the IAL3 group and a second allow policy that does not is open, and a policy that lists no permitted authenticator classes at all is not the same as one that permits only AAL3. Method 2 cannot see whether a correctly configured policy produces a deny at runtime.
Method 3: Behavioral Probing
Prove, by attempting it, that an unproofed identity cannot reach a boundary application. A hand-crafted token with the claim stripped only proves the gateway validates signatures; the question is whether an account valid in every respect except proofing gets refused, which needs a dedicated test identity configured like a boundary user, with no proofing record, attempting a health route behind the policy that protects production.
The negative probe automates cleanly because it needs no AAL3 success. The positive probe does not: a daily unattended AAL3 login would put a hardware authenticator, its activation factor, and a proofed person's credential into automation, which weakens what you are validating. Run it attended instead, by a proofed operator with their own key, after any change to the enforcement path and on a documented cadence; real proofed users authenticate every day and Method 4 evidences that. With Method 5 in place, the attended run adds a third case: a hardware key that never entered through a permitted binding path, expecting a refusal. Skip synthetic revocation tests; re-establishing a revoked canary means a new attended session, and revocation latency is measured from real events in Method 4.
Method 4: Session-to-Record Reconciliation
Join successful sessions from the gateway, the identity provider, and the cloud provider's audit trail against a status table fed by the proofing provider's webhooks, and assert that every session maps to a record valid at session_start. The authority is the event stream: what happened, not what was supposed to happen.
Two completeness controls make this method worth its place: a source inventory, every access path into the boundary and the log source that covers it, reconciled against what is actually ingested so a new bastion or console path is a finding the day it appears; and pipeline freshness, the age of the newest event per source against a floor, so a source that goes quiet is a failure rather than a clean day. Method 4 detects only known, ingested, correctly classified paths; the inventory keeps that set honest.
Revocation latency lives here too, in two parts: enforcement acknowledgement, from the revocation event to the last required enforcement point confirming the change in its own audit log, and session invalidation, from revocation to termination of every session open at the time, with a session still open counted as a failure rather than a missing number. A denied attempt after revocation is a lower bound; the absence of any successful session after it is the assertion.
Method 5: Bound-Authenticator Posture at Authentication
Refuse any authentication to a boundary application unless two things hold: the credential presented is recorded in the account's authenticator record as AAL3-eligible and as having entered through one of the three permitted binding paths, and the transaction itself achieved AAL3. The distinction matters because AAL describes a transaction, not a credential. A hardware-bound FIDO2 or PIV credential is eligible for AAL3; whether a login achieved it depends on both factors being exercised, user verification, demonstrated intent, a replay-resistant and phishing-resistant protocol, and approved cryptography, which the verifier knows and can expose as flags. Either check alone is incomplete.
This turns proofing from an account-level property into a session-level one. Group membership can be granted by hand, synced late, or bypassed by a policy bug; a credential recorded at the attended session, bound under AAL3 authentication with notification, or bound after a recovery comparison cannot be conjured by any of those. An unproofed account fails regardless of what any attribute says; a revoked subject fails on the next attempt. Attestation belongs at binding, not at login: 63B-4 has the credential service provider determine an authenticator's characteristics at binding, and at authentication the verifier checks the assertion against the registered key and consults what was recorded.
Two implementation patterns. The stronger one closes the enrollment path: credentials enter the identity provider for boundary users only through the three permitted workflows, with self-service and help-desk direct registration disabled for that population. Some identity providers can register a FIDO credential on a user's behalf by API; capabilities vary, some are preview features, and some still require a WebAuthn ceremony from the user, so verify yours first. Where enrollment cannot be closed, the policy engine evaluates the credential against the authenticator record on every authentication and every denial is investigated the day it occurs. Method 2 verifies the policy is deployed; Method 3's attended probe validates that it fires. The same decision log is direct evidence for KSI-IAM-APM.
Method 5 cannot see whether the binding event was legitimate; that is Method 1's job. It cannot see paths that do not authenticate through the policy engine; that is Method 4's, and the source inventory's.
What the Methods Still Share
Diversified is not independent. An assessor will find the dependencies that remain; better that the Security Decision Record already lists them.
| Shared dependency | Methods that rely on it | If it is wrong or compromised | What limits the damage |
|---|---|---|---|
| Proofing provider ledger and webhooks | M1, M4 (status join), M5 in the open-enrollment model | A fabricated or missing event passes M1's existence check and M4's join | Package and hash in your custody; sponsor attestation for a person nobody expected; applicant confirmation or independent telemetry if a malicious provider is in scope; closed enrollment for M5 |
| Identity provider | All five | The largest shared dependency; an IdP compromise is beyond what this measure can self-validate | M4's gateway and cloud audit logs do not originate in the IdP; other KSI-IAM measures cover the IdP itself |
| Gateway or enforcement point | M2, M3, M4, M5 (if evaluated there) | Configuration reads correctly but does not enforce | M3 tests behavior; M4 sees the resulting sessions; M5 at the IdP is a second enforcement point |
| Log pipeline | M4 | Silent drop looks like a clean day | Source inventory and freshness checks |
| Your evidence store | M1 | Altered or deleted package | Hash mismatch or missing-package finding; write-once storage |
| Your own automation | All | A method stops running | methods_reporting metric; unknown status is a finding |
The value is not that no single failure can fool all five. It is that most are caught by at least two methods reading different things, and the ones that are not are named.
Failure Modes Against Methods
The matrix shows which methods detect which failures, assuming the shared dependencies above are honest. The right-hand column shows what four readers of the same directory label would report; rows where they all pass illustrate why we recommend diversity, not that such a set fails the rule.
| Failure | M1 Ledger | M2 Config | M3 Probe | M4 Sessions | M5 Posture | Label-readers |
|---|---|---|---|---|---|---|
| Admin hand-sets IAL3 attribute on unproofed account | Catch | Pass | Pass | Catch | Catch (no bound key) | All pass |
| Audit package altered or replaced in evidence store | Catch (hash) | Pass | Pass | Pass | Pass | All pass |
| Console change removes IAL3 group from gateway policy | Pass | Catch | Catch | Catch (first unproofed login) | Catch (key still required) | IaC only, if pipeline ran |
| Second allow policy added that bypasses the IAL3 rule | Pass | Catch (all paths evaluated) | Catch | Catch | Catch | All pass |
| New bastion path added, not in source inventory | Pass | Pass | Pass | Catch (inventory) | Pass | All pass |
| Record revoked; account still active | Catch (gate, sweep) | Pass | Pass | Catch (latency) | Catch (next auth) | All pass |
| Help desk registers a replacement key with no AAL3 auth or recovery comparison | Catch (sweep) | Pass | Pass | Pass | Catch (first use) | All pass |
| Password or OTP fallback enabled on a boundary app | Pass | Catch | Pass | Pass | Catch (AAL3 not achieved) | All pass |
| Proofing backfilled after access was granted | Catch | Pass | Pass | Catch (historical) | Pass | All pass |
| Group sync stalls; unproofed users retain access | Pass | Pass | Catch | Catch | Catch | All pass |
| Log source goes quiet for 12 hours | Pass | Pass | Pass | Catch (freshness) | Pass | All pass |
| Provider proofs a session for a person nobody expected | Catch (sponsor attestation) | Pass | Pass | Pass | Pass | All pass |
| Provider proofs a session for the expected worker | Pass | Pass | Pass | Pass | Pass | All pass |
The last row is deliberate. Nothing in the automated set catches it; only applicant confirmation over a channel you control, an independent witness, or session telemetry outside the provider's control does. Whether that threat is in scope is a shared-responsibility decision, and it belongs in the record either way.
Metrics, History, and Method Health
FRC-CSX-MOT requires 18 months of historical metrics at Class D, and SDR-CSX-KMT already requires daily data for up to a year at Class C, with Class D expected to "significantly supersede" that. Emit one datapoint per method per day and retain it for a defined period of at least 18 months; we suggest the life of the certification plus one assessment cycle, written into your records schedule rather than left as "indefinitely."
| Metric | Source | Target |
|---|---|---|
coverage_pct by tier (all, privileged) |
M1 | 100 |
violations by reason |
M1, M4, M5 | 0 |
population by tier |
M1 | Tracked; unexplained drops are a completeness finding |
grants_blocked |
M1 gate | Tracked |
config_drift_findings |
M2 | 0 |
negative_probe_refused |
M3 | 1 on every run |
unmatched_sessions by source |
M4 | 0 |
sources_missing_from_inventory, source_max_event_age |
M4 | 0; below floor |
revocation_ack_seconds, session_invalidation_seconds, sessions_open_after_revocation |
M4 | Below the bounds you commit to; 0 |
auth_denied by reason |
M5 | Tracked; every denial is investigated |
methods_reporting |
All | 5 of 5 |
The last row operationalizes "persistently": a method that has not reported within its stated cycle is a status of unknown, and unknown is a finding.
Registering the Methods in the Security Decision Record
SDR-CSX-KSI requires, per indicator, the measures and their objectives, the cycle of each persistent measure, verification that the measures demonstrate the indicator and that the automation is accurate and sufficient, and validation that the measures are working. The official SDR JSON schema carries that as a keySecurityIndicators array of statements, tests, and typed evidence, inside a document that also requires certificationPackageOverviewUri and fedRampRequirements. The implementation guide has a schema-shaped fragment for the identity-proofing measure only; the full KSI-IAM-AAM entry also carries the provisioning, deprovisioning, role and group change, privilege change, and exception measures with their own methods.
Method 5 is also recorded against KSI-IAM-APM, and the revocation evidence supports KSI-IAM-SUS. FRC-CSO-MRA keeps the provider accountable for everything in the package, including third-party data: the ledger is the proofing provider's, but the reconciliation logic, the assertions, and the metric are yours.
Scoping the Population
A coverage metric over the wrong denominator is worse than no metric. Our earlier article defined the population as privileged operators, break-glass holders, and vendor personnel with production access. That is the floor and the scope we would expect an assessor to insist on. For Class D we recommend every human identity with access into the boundary, for three reasons.
FRC-CSX-MAS says providers should apply all indicators to all aspects of the offering within the Minimum Assessment Scope, and FedRAMP's definition of an information resource includes personnel; a support engineer with read access to a boundary system is inside the scope on the same reading that puts a domain administrator there. Privilege is a state, not a person: the insider scenarios that concern the customers we work with rarely begin with an administrator account, and lateral movement rarely arrives through a formal grant that Method 1's gate would catch. And the cost is proportionate: for many providers the boundary population is in the hundreds, an attended session on hardware that comes to the individual typically takes 3 to 10 minutes in our deployments, and onboarding can begin the same day.
Record the decision in the Security Decision Record either way; a privileged-only scope with written reasoning is defensible. Report coverage for both tiers regardless. A sixth method, if you have room, is population completeness: reconcile the humans with boundary access as seen by HR, the identity provider, cloud IAM, and PAM against each other. It is the only check here that tests the denominator directly.
How Trust Swiftly Fits
Methods 1, 4, and 5 depend on the proofing provider producing something your automation can reconcile against. Every attended IAL3 session, on an in-office kiosk or a Remote Kit shipped to the individual, produces one audit package containing the outcome, evidence validation and verification results, PAD results conformant to ISO/IEC 30107-3:2023, operator and chain-of-custody records, the retained biometric, and the identifier of the authenticator bound during the session. Customers who choose the minimal-retention configuration then have the underlying records deleted on our side, leaving the hash ledger and status; recovery bindings through our biometric comparison are recorded as ledger events. A real-time API returns entries by reference ID, webhooks push completion, binding, and revocation events, and the same evidence is available in OSCAL using the machine-readable approach we described for Rev5 packages. If your risk model treats the provider as a potential adversary, raise it with us; that belongs in the shared-responsibility discussion, not in a marketing claim.
Frequently Asked Questions
Is FedRAMP 20x Class D available now?
No. The rule text exists, but the Class D path is a Phase 4 pilot targeted for FY27 Q1 to Q2, with metric specifics set during it. Providers at High today remain on Rev5, where IA-12 and IA-5 already require IAL3. The reason to build now is that history accumulates only forward.
Does FedRAMP require the four methods to use different sources of truth?
No. FRC-CSX-VVK requires at least four automated methods; SDR-CSX-KSI requires verification that the automation is accurate and sufficient; neither defines a distinctness test. Diversity of what each method reads is our recommendation for making the sufficiency case, and the shared-dependency table above is its honest companion.
Can someone replace a lost YubiKey without another attended session?
Yes, and the path depends on what they still hold. With another AAL3 authenticator still bound, adding the replacement is a post-enrollment binding under SP 800-63B-4: authenticate at AAL3 with the existing key, bind the new one, and the credential service provider sends an independent notification. With every AAL3 authenticator lost, it is account recovery, and for an IAL3-proofed account 63B-4 requires a biometric comparison against the sample retained from the attended session before a new key is bound. A help-desk registration that does neither is what Methods 1 and 5 exist to catch.
Does this replace the annual independent assessment?
No. IVV-CSX-AIA still requires an annual independent assessment. What changes is what the assessor is assessing: instead of sampling onboarding tickets, they are verifying that the methods are accurate and sufficient and validating that they are running. The assessor and agency process does not otherwise change.
The Bottom Line
Four automated methods is the floor the rule sets. Four readers of the same directory attribute meet the letter of it and may leave an assessor unconvinced of the substance. The architecture we would defend reads five different things and writes down what those five still share. Check state transitions in real time, sweep daily, build the failure matrix and the dependency table for your own stack, register the cycles in the Security Decision Record, and start recording.
Explore our NIST IAL3 verification solution and federal identity proofing deployment options, read the implementation guide for the code behind each method, or talk to us about producing proofing records your validation methods can reconcile against.
