TryMellon
Navigation

AAL & IAL Claims — Authentication and Identity Assurance Levels

TryMellon's authentication assurance level (AAL) and identity assurance level (IAL) claims, conforming to NIST SP 800-63-4. Conservative interpretation: synced passkeys reach AAL2-strong, not AAL3.

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:

  1. Private key replication to cloud provider: Cloud sync providers (Apple, Google, 1Password) can access the synced passkey’s plaintext during synchronization.
  2. Key compromise scope: If either the cloud provider or TryMellon is compromised, the private key is exposed.
  3. 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

TierDefinitionExampleNIST SourceEnforcement
AAL2Multi-factor cryptographic authentication with verifier presenceiPhone Face ID synced to iCloud, Android fingerprint synced to Google Password ManagerNIST SP 800-63-4 §5.1.7Default for all accounts
AAL2-strongMulti-factor + cryptographic attestation chainiPhone passkey + iCloud end-to-end encryption + FIDO Level 2+ certification via AAGUID validated by FIDO MDSTryMellon-defined, derived from FIDO L2+ certification + attestation evidencePer-Tenant configuration: minCertificationLevel: 'FIDO_L2' (see ADR-029)
AAL3 strictHardware-bound credential, never synced, FIDO Level 3+ certifiedYubiKey 5 NFC, Windows Hello with dedicated TPM, security keysNIST SP 800-63-4 §5.1.5Per-Tenant strict policy: blockSoftwareAuthenticators: true + minCertificationLevel: 'FIDO_L3' (see ADR-029)

IAL: Three Tiers from Anonymous to Verified

TierDefinitionTryMellon ImplementationEnforcement
IAL1No identity verification; anonymousUser registers with passkey only; zero PII requiredDefault for all accounts
IAL2 VerifiedVerified identifier (cryptographic or OTP proof)Email linked + OTP-verified, or blockchain wallet (ECDSA-signed SIWE), or custom verified identity flowPer-Tenant opt-in; Layer 1 Identity Linking
IAL3 Partner-BridgedLegal identity verified in-person or via regulated partnerKYC validation (DNI/passport) via Onfido, Persona, or Veriff bridgeNever 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 of AAL2, AAL2-strong, AAL3
  • ial_tier_achieved: One of IAL1, IAL2, IAL3
  • attestation_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 by aal_tier_achieved)
  • Audit Log API: GET /v1/audit-logs?event_type=authentication.* (requires API key)
  • Webhook events: Subscribe to authentication.completed events and inspect aal_tier_achieved payload

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:

  1. Configure Tenant Policy:

    POST /v1/admin/attestation-policies
    {
      "blockSoftwareAuthenticators": true,
      "minCertificationLevel": "FIDO_L3"
    }
  2. Enforcement mode: Set to block (reject non-compliant credentials) or audit (log warnings, allow registration).

  3. 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.


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.