AAL & IAL Claims
What are AAL and IAL?
Authenticator Assurance Level (AAL) measures the strength of authentication mechanisms used to prove a user’s identity.
Identity Assurance Level (IAL) measures the confidence that a claimed identity is genuine and accurate.
TryMellon operates both dimensions independently: a user may authenticate strongly (AAL3) with minimal identity verification (IAL1), or authenticate with standard methods (AAL2) while maintaining verified identity (IAL2).
NIST SP 800-63-4 Framework
TryMellon’s assurance levels align with the NIST Special Publication 800-63-4, the US federal standard for authentication and identity proofing. This standard is the baseline for regulated industries: financial services (PSD2 SCA), government contractors, and SOC2 audits globally.
Our implementation makes conservative interpretations where the standard permits flexibility, prioritizing defensibility in compliance audits over marketing claims.
TryMellon’s AAL Stance: Synced Passkeys = AAL2-strong, Never AAL3 strict
The Conservative NIST Interpretation
Synced passkeys (Apple iCloud Keychain, Google Password Manager, 1Password) reach AAL2-strong maximum — NOT AAL3, according to NIST SP 800-63-4 §5.1.5.
Why? NIST requires AAL3 to meet “verifier impersonation resistance” — the authenticator must be resistant to compromise of the verifier (TryMellon’s servers). Cloud-synced authenticators fail this test because:
- Private key replication to cloud provider: Cloud sync providers (Apple, Google, 1Password) can access the synced passkey’s plaintext during synchronization.
- Key compromise scope: If either the cloud provider or TryMellon is compromised, the private key is exposed.
- NIST quotes §5.1.5: “The verifier SHALL ensure that [the cryptographic key] resists [attacks on the credential storage mechanism].” Synced keys stored in cloud provider infrastructure are not isolated from provider compromise.
TryMellon’s Three AAL Tiers
| Tier | Definition | Example | NIST Source | Enforcement |
|---|---|---|---|---|
| AAL2 | Multi-factor cryptographic authentication with verifier presence | iPhone Face ID synced to iCloud, Android fingerprint synced to Google Password Manager | NIST SP 800-63-4 §5.1.7 | Default for all accounts |
| AAL2-strong | Multi-factor + cryptographic attestation chain | iPhone passkey + iCloud end-to-end encryption + FIDO Level 2+ certification via AAGUID validated by FIDO MDS | TryMellon-defined, derived from FIDO L2+ certification + attestation evidence | Per-Tenant configuration: minCertificationLevel: 'FIDO_L2' (see ADR-029) |
| AAL3 strict | Hardware-bound credential, never synced, FIDO Level 3+ certified | YubiKey 5 NFC, Windows Hello with dedicated TPM, security keys | NIST SP 800-63-4 §5.1.5 | Per-Tenant strict policy: blockSoftwareAuthenticators: true + minCertificationLevel: 'FIDO_L3' (see ADR-029) |
IAL: Three Tiers from Anonymous to Verified
| Tier | Definition | TryMellon Implementation | Enforcement |
|---|---|---|---|
| IAL1 | No identity verification; anonymous | User registers with passkey only; zero PII required | Default for all accounts |
| IAL2 Verified | Verified identifier (cryptographic or OTP proof) | Email linked + OTP-verified, or blockchain wallet (ECDSA-signed SIWE), or custom verified identity flow | Per-Tenant opt-in; Layer 1 Identity Linking |
| IAL3 Partner-Bridged | Legal identity verified in-person or via regulated partner | KYC validation (DNI/passport) via Onfido, Persona, or Veriff bridge | Never in-house; Layer 7 KYC Bridge (future roadmap) |
Important: No Self-Asserted IAL2
TryMellon does not claim IAL2 for self-asserted identifiers (e.g., “I assert my email is foo@example.com”). An identifier only counts as IAL2 if:
- Cryptographically verified (e.g., wallet ECDSA signature), OR
- OTP-verified (user receives and confirms a one-time passcode), OR
- Partner-verified (regulated identity proofing service validates government ID)
How to Verify Which Tier Your User Achieved
TryMellon emits audit log structured fields for every authentication and credential registration event:
{
"event_type": "authentication.completed",
"user_id": "user_xyz",
"credential_id": "cred_123",
"aal_tier_achieved": "AAL2-strong",
"ial_tier_achieved": "IAL2",
"attestation_status": "verified_fido_l2",
"timestamp": "2026-04-28T14:32:00Z"
}
Audit log fields:
aal_tier_achieved: One ofAAL2,AAL2-strong,AAL3ial_tier_achieved: One ofIAL1,IAL2,IAL3attestation_status: Hardware certification level (verified_fido_l1,verified_fido_l2,verified_fido_l3,unverified, etc.)
Access these fields via:
- TryMellon Admin Dashboard:
/dashboard/audit-logs(filter byaal_tier_achieved) - Audit Log API:
GET /v1/audit-logs?event_type=authentication.*(requires API key) - Webhook events: Subscribe to
authentication.completedevents and inspectaal_tier_achievedpayload
Compliance Audit Guidance
SOC2 Type II
Reference documentation:
For your auditor:
TryMellon’s assurance level claims follow NIST SP 800-63-4 conservatively. Synced passkeys are claimed as AAL2-strong, not AAL3 — this aligns with §5.1.5’s requirement that AAL3 must resist verifier impersonation.
Evidence of your configured AAL/IAL tier is auditable per-event in the Audit Log (fields aal_tier_achieved, ial_tier_achieved, attestation_status). Encryption in transit (TLS 1.3) and at rest (PostgreSQL AES-256-GCM) are standard.
PSD2 Strong Customer Authentication (SCA)
Regulatory requirement: SCA mandates two-factor authentication for high-value payments (> €50).
TryMellon satisfies PSD2 SCA with:
- AAL2 minimum: Passkey + device-bound credential meets the “something you have + something you are” rule.
- AAL2-Strong recommended: For transactions > €500 or high-risk scenarios (unusual geography, velocity alerts).
Consult your PSD2 compliance team; TryMellon provides the authentication strength, and you layer transaction risk rules.
ISO 27001 / ENISA Framework
Identity assurance requirement: ENISA recommends IAL2 for verified-identity workflows (e.g., Know Your Customer flows).
TryMellon provides:
- IAL1 default: No PII stored; suitable for public-facing services.
- IAL2 via Layer 1 (Identity Linking): Email + OTP verification, wallet ECDSA signature, or custom verified flow.
- IAL3 via Layer 7 (KYC Bridge): Partner integrations (Onfido, Persona, Veriff) for regulated identity proofing.
Roadmap: Path to AAL3 Strict
Strict AAL3 enforcement is available today via tenant-specific attestation policies (ADR-029). To activate:
-
Configure Tenant Policy:
POST /v1/admin/attestation-policies { "blockSoftwareAuthenticators": true, "minCertificationLevel": "FIDO_L3" } -
Enforcement mode: Set to
block(reject non-compliant credentials) oraudit(log warnings, allow registration). -
User guidance: Instruct users to register hardware security keys (YubiKey 5, Windows Hello with TPM, etc.). Cloud passkeys will be rejected.
Future layers (post-Series A):
- Layer 7 (KYC Bridge): IAL3 partner integrations for regulated identity proofing.
- Layer 6 (Trust Signals Export): Risk and assurance signals consumable by external anti-bot and fraud engines.
Related Resources
- NIST SP 800-63-4 — Full federal authentication standard
- FIDO Alliance Metadata Service — Certification and device metadata
- Charter v1.0 — Identity & Authority Model — TryMellon product decisions
- ADR-029: Attestation Policy Engine — Technical enforcement details
- ADR-016: AAGUID Resolution — Device name resolution
- ADR-040: SIWE Wallet Integration — Blockchain-based verified identity
Questions?
Contact our compliance team at security@trymellon.com or your account representative. For SOC2/PSD2/ISO 27001 audit support, we provide pre-built attestation templates and audit evidence exports.