Passkey + Liveness Policy Template

Your authentication policy likely treats passkeys and biometric liveness as separate controls. That's a gap. By unifying them in a single policy framework, you can tackle both credential phishing and presentation attacks without increasing authentication friction.

This template provides a policy structure that combines FIDO2 passkey requirements with liveness verification rules. Use it to define when each control applies, how they interact, and what your verification thresholds should be.

Purpose of the Template

This policy template structures your authentication requirements when deploying passkeys alongside biometric liveness detection. It's designed for organizations needing phishing-resistant authentication (passkeys) and protection against presentation attacks like deepfakes, printed photos, or video replay (liveness).

The template covers three scenarios:

• Standard authentication: Day-to-day logins where passkey alone is sufficient
• Step-up authentication: High-value transactions requiring liveness verification on top of passkey
• Enrollment and recovery: Initial registration and account recovery flows needing both controls

You'll define risk tiers, specify which authenticator types qualify, set liveness detection thresholds, and document fallback procedures.

Prerequisites

Before customizing this template, ensure you have:

• FIDO2-certified passkey infrastructure deployed or in pilot (WebAuthn API integration, credential storage, attestation validation)
• Liveness detection service with an API for authentication flows (vendor-hosted or self-hosted)
• Risk scoring capability to trigger step-up authentication based on user behavior, device trust, or transaction attributes
• Identity provider supporting conditional authentication policies (most modern IdPs support this through policy engines or adaptive authentication modules)

Document your current authentication assurance levels and map them to NIST 800-63-3 Authenticator Assurance Levels (AAL1, AAL2, AAL3) or equivalent.

The Template

# Unified Passkey + Liveness Authentication Policy
# Version: 1.0
# Last Updated: [DATE]
# Policy Owner: [IAM ARCHITECT NAME/TEAM]

policy_scope:
  applies_to:
    - workforce_users: true
    - customer_users: true
    - privileged_accounts: true
  excluded_contexts:
    - emergency_access_accounts: true  # Define break-glass separately
    - service_accounts: true

authenticator_requirements:
  passkey_baseline:
    attestation_required: true
    allowed_authenticator_types:
      - platform_authenticator: true  # Device-bound biometric or PIN
      - roaming_authenticator: true   # Hardware security keys
    user_verification_required: true  # Biometric or PIN at passkey use
    
  liveness_verification:
    provider: [VENDOR_NAME or INTERNAL_SERVICE]
    detection_modes:
      - active_liveness: true   # User performs action (blink, turn head)
      - passive_liveness: false # Set true if your vendor supports passive
    minimum_confidence_score: 0.85  # Adjust based on vendor scale (0-1 or 0-100)
    max_verification_attempts: 3
    verification_timeout_seconds: 45

authentication_tiers:
  tier_1_standard:
    description: "Daily access to standard applications and data"
    required_controls:
      - passkey_authentication: required
      - liveness_verification: not_required
    applies_to:
      - email_access: true
      - collaboration_tools: true
      - internal_portals: true
    
  tier_2_elevated:
    description: "Access to sensitive systems or medium-risk transactions"
    required_controls:
      - passkey_authentication: required
      - liveness_verification: required
    applies_to:
      - financial_systems: true
      - customer_data_access: true
      - privileged_account_elevation: true
    step_up_triggers:
      - transaction_value_exceeds: [CURRENCY_AMOUNT]
      - access_from_new_device: true
      - geolocation_anomaly: true
      - time_since_last_liveness_check_hours: 8
    
  tier_3_critical:
    description: "High-assurance operations requiring continuous verification"
    required_controls:
      - passkey_authentication: required
      - liveness_verification: required
      - session_binding: required  # Re-verify liveness mid-session
    applies_to:
      - wire_transfers: true
      - production_infrastructure_access: true
      - legal_document_signing: true
    session_liveness_recheck_interval_minutes: 15

enrollment_policy:
  initial_registration:
    passkey_enrollment:
      - verify_email_or_phone: required
      - liveness_check_at_enrollment: required  # Bind face to account
      - minimum_passkeys_required: 1
      - recommended_passkeys: 2  # Platform + roaming for redundancy
    
  recovery_procedures:
    passkey_lost_or_compromised:
      - liveness_verification: required
      - secondary_factor: required  # [One-Time Password](/glossary/one-time-password) to known contact
      - manual_review_threshold: [Define risk score that triggers human review]
      - revoke_all_existing_passkeys: true
      - re_enrollment_cooling_period_hours: 24

failure_handling:
  liveness_verification_failure:
    after_max_attempts:
      - block_authentication: true
      - alert_security_team: true
      - require_manual_identity_verification: true
    
  passkey_authentication_failure:
    after_max_attempts: 5
    lockout_duration_minutes: 30
    
  fallback_authentication:
    allowed: false  # No password fallback; prevents downgrade attacks
    exception_process: "Contact IT service desk with government-issued ID"

compliance_mapping:
  - standard: "NIST 800-63-3"
    tier_1_maps_to: "AAL2"
    tier_2_maps_to: "AAL2"
    tier_3_maps_to: "AAL3"
  - standard: "[eIDAS](/glossary/eidas)"
    tier_3_maps_to: "High Level of Assurance"

audit_and_monitoring:
  log_events:
    - passkey_registration
    - passkey_authentication_attempt
    - liveness_verification_attempt
    - liveness_verification_failure
    - step_up_authentication_triggered
    - policy_exception_granted
  
  review_frequency:
    - liveness_confidence_score_distribution: monthly
    - false_rejection_rate: monthly
    - policy_exception_audit: quarterly

Customizing the Template

Start with policy_scope. For a phased rollout, set workforce_users: true and customer_users: false initially, then switch after your pilot.

In authenticator_requirements.liveness_verification, your minimum_confidence_score depends on your vendor's scale and risk tolerance. If scores range from 0 to 100, a threshold of 85 is reasonable. For high-assurance scenarios (tier 3), consider 90 or higher. Run a pilot with logging enabled to see your false rejection rate before setting this in production.

The authentication_tiers section maps your applications and risk levels. Replace placeholder categories with your systems. For step_up_triggers, define your transaction value threshold based on your risk appetite. Some organizations step up at $10,000, others at $1,000.

In enrollment_policy.recovery_procedures, the manual_review_threshold should reference your identity provider's risk score. If you don't have risk scoring yet, set this to trigger manual review for all recovery attempts until you build that capability.

Set fallback_authentication.allowed: false to ensure phishing resistance. Allowing password fallback creates a downgrade path attackers will exploit. Document and staff your exception process.

Validation Steps

After deploying this policy, validate it in three phases:

Phase 1: Enrollment Verification (Week 1)

Ensure new users complete both passkey registration and initial liveness verification. Check enrollment logs to confirm liveness_check_at_enrollment: required is enforced. Look for users who registered a passkey but skipped liveness; that's a policy gap.

Phase 2: Authentication Flow Testing (Week 2-3)

Test each tier manually. Authenticate to a tier 1 application and confirm you're not prompted for liveness. Then access a tier 2 resource and verify liveness triggers. For tier 3, set a timer and confirm session liveness rechecks at your defined interval.

Test your step-up triggers. If you configured access_from_new_device: true, log in from a new device and confirm liveness is required even for tier 1 resources.

Phase 3: Failure Handling (Week 4)

Deliberately fail liveness verification up to your max_verification_attempts. Confirm you're locked out and your security team gets an alert. Then test your exception process; call your IT service desk and verify they follow the documented procedure.

Pull audit logs monthly and calculate your false rejection rate: (liveness verification failures by legitimate users) / (total liveness verification attempts). If this exceeds 2%, your minimum_confidence_score is likely too high. Lower it by 5 points and re-measure.

Review policy exceptions quarterly. If you're granting more than five exceptions per month, either your policy is too strict or your recovery procedure needs work.