Incremental Authentication:
Why Verify What Hasn't Changed?

Traditional authentication treats every request the same: full verification, every time. But if a user's device, location, and session context haven't changed, why re-verify everything?

H33's incremental authentication takes a smarter approach. When only a small portion of the authentication context changes, we only verify the delta — delivering 4x+ faster re-authentication for typical updates.

How It Works

H33 tracks authentication context as a set of claims, each with its own verification status:

• Identity claims: User ID, email, phone number
• Device claims: Fingerprint, trusted device status
• Location claims: IP geolocation, network type
• Temporal claims: Session age, last activity
• Behavioral claims: Typing patterns, interaction style

When a request arrives, we compute the delta between current and previous context. Only changed claims require re-verification. Under the hood, each claim category maps to a distinct cryptographic proof that can be independently validated. Identity and biometric claims pass through H33's BFV fully homomorphic encryption pipeline (N=4096, 32 users per ciphertext batch), while device and location claims are verified via lightweight SHA3-256 hash comparisons against the existing attestation record.

// Initial authentication - full verification
const initial = await h33.auth.fullStack({
  userId: 'user_123',
  context: fullContext
});

// Context update - only IP changed
const updated = await h33.auth.incrementalUpdate({
  sessionId: initial.sessionId,
  delta: {
    ipAddress: newIpAddress  // Only this changed
  }
});
// Verifies just the location claim - much faster

The Cost Anatomy of Full vs. Incremental Auth

To understand why incremental auth matters, consider what a full H33 authentication actually computes. The production pipeline executes three cryptographic stages in sequence, each with measurable cost:

The FHE stage dominates at ~82% of total latency. When a user's biometric template has not changed — which is the case for every request except initial enrollment or explicit re-enrollment — incremental auth bypasses the entire FHE inner product computation. The ZKP lookup, already cached in an in-process DashMap at 0.085µs, is similarly skippable when the identity claim graph is stable. What remains is a partial attestation: the system re-hashes only the changed claim fields, appends them to the existing Dilithium-signed attestation envelope, and produces a delta signature covering the modified subset.

Use Cases

Mobile users moving between networks: When a user switches from WiFi to cellular, only the network context changes. Incremental auth verifies the new IP without re-checking biometrics. In production, this reduces the per-auth cost from ~42µs to under 5µs — a hash comparison plus a lightweight claim update on the existing Dilithium attestation.

Permission escalation: User requests access to a sensitive resource. Incremental auth adds the permission claim without re-authenticating identity. The new claim is appended to the attestation envelope and signed, but the FHE biometric verification and ZKP identity proof remain valid from the original session.

Session extension: User is still active but session is aging. Refresh temporal claims without full re-verification. The only cryptographic work is a SHA3-256 digest over the updated timestamp and a single Dilithium signature operation (~244µs for the batch, amortized across all 32 users in the ciphertext slot).

Claim Dependency Graph

Not all claims are independent. H33 models claim relationships as a directed acyclic graph (DAG) where certain changes propagate re-verification requirements upward. For example, a device fingerprint change invalidates all claims that depend on device trust, including behavioral biometrics that were calibrated to a specific hardware profile.

// Claim dependency configuration
const claimDAG = {
  device_fingerprint: {
    invalidates: ['behavioral_biometric', 'trusted_device', 'device_posture'],
    triggers: 'full_auth'  // Device change = full re-verification
  },
  ip_address: {
    invalidates: ['geolocation', 'network_type'],
    triggers: 'partial_auth'  // Only location claims re-verified
  },
  session_timestamp: {
    invalidates: [],
    triggers: 'attestation_only'  // Just re-sign the temporal claim
  }
};

The DAG ensures that incremental auth never produces a security gap. If a changed claim sits at the root of a dependency chain, all downstream claims are automatically scheduled for re-verification. The system evaluates the propagation cost and, if the total re-verification scope exceeds 60% of the full claim set, it falls back to full authentication rather than computing a complex partial proof.

Security Model

Incremental authentication maintains full security through:

• Claim dependencies: Some claims require others to be fresh (e.g., location changes may require device re-verification)
• Risk scoring: High-risk deltas trigger full re-authentication
• Anomaly detection: Unusual delta patterns are flagged — for instance, a location claim changing three times in 10 seconds without a device change suggests proxy rotation
• Claim expiration: All claims have TTLs requiring periodic refresh, with identity claims expiring at 15 minutes and biometric claims at 24 hours
• Post-quantum integrity: Every attestation envelope, whether full or incremental, is signed with Dilithium (ML-DSA), ensuring that delta proofs are quantum-resistant from day one

When Full Auth is Triggered

Certain conditions always require full authentication:

• Session expired or invalidated
• Device fingerprint changed
• Geographic location moved significantly (>500km or cross-border)
• Risk score exceeds threshold (default 0.6)
• Sensitive operation requested (financial transfers, data export, account deletion)
• Explicit logout/re-login
• Claim dependency propagation exceeds 60% of total claim set

Implementation

// Configure incremental auth behavior
const authConfig = {
  incrementalAuth: {
    enabled: true,
    maxDeltaAge: '15m',      // How old can unchanged claims be
    riskThreshold: 0.6,       // Trigger full auth above this
    sensitiveOperations: ['transfer', 'delete', 'export'],
    claimTTL: {
      identity: '15m',
      biometric: '24h',
      device: '7d',
      location: '5m',
      behavioral: '1h'
    }
  }
};

// The SDK handles delta computation automatically
app.use(h33.middleware(authConfig));

// In your routes, auth is already incremental
app.post('/api/data', async (req, res) => {
  // req.auth contains current claims
  // req.auth.deltaPath shows which claims were re-verified
  // req.auth.latencyUs shows actual verification time
});

The Performance Impact

For applications where user context is relatively stable between requests, incremental authentication delivers significant improvements. In production workloads on Graviton4 (c8g.metal-48xl, 96 cores), H33 sustains 1.595 million authentications per second at ~42µs per auth for full-stack verification. With incremental auth enabled, the majority of follow-up requests — those where only temporal or location claims change — bypass the FHE and ZKP stages entirely, reducing per-auth latency by 80-90% while maintaining identical post-quantum security guarantees.

Combined with session resume and proof caching, H33's intelligent authentication system minimizes redundant verification while maintaining complete security. The net effect: your users experience sub-10µs re-authentication on stable sessions, and your infrastructure budget scales with actual security work performed rather than redundant cryptographic ceremony.