Skip to content

Template Selection Guide

Target Audience: Platform Administrators, Security Architects
Version: 3.0.0 Last Updated: December 2025


Decision Tree

flowchart TD
    Start(["Which regulatory<br/>framework applies?"]) --> Q1{"Operating in<br/>Germany?"}

    Q1 -->|Yes| BSI["BSI_HYBRID_ENFORCED<br/>German federal compliance"]
    Q1 -->|No| Q2{"Operating in<br/>France?"}

    Q2 -->|Yes| ANSSI["ANSSI_HYBRID_ENFORCED<br/>French defense compliance"]
    Q2 -->|No| Q3{"EU Telecommunications<br/>5G/6G?"}

    Q3 -->|Yes| ETSI["ETSI_HYBRID_ENFORCED<br/>ETSI TS 103 744"]
    Q3 -->|No| Q4{"Multi-national<br/>EU operations?"}

    Q4 -->|Yes| EU["EU_UNIFIED_HYBRID<br/>BSI, ANSSI or ETSI coverage"]
    Q4 -->|No| Q5{"US Federal<br/>or Defense?"}

    Q5 -->|Yes| NIST["NIST_HYBRID_OPTIONAL<br/>US federal compliance"]
    Q5 -->|No| Q6{"High-risk<br/>system?"}

    Q6 -->|Yes| ENISA["ENISA_RISK_BASED<br/>Risk-based approach"]
    Q6 -->|No| DEFAULT["DEFAULT<br/>No restrictions"]

    style BSI fill:#ffe6e6
    style ANSSI fill:#ffe6e6
    style ETSI fill:#e6f3ff
    style EU fill:#fff3e6
    style NIST fill:#e6ffe6
    style ENISA fill:#f3e6ff
    style DEFAULT fill:#f0f0f0

Template Comparison

Composite Pairs Each Template Admits

The templates are not ordered on one strictness axis: each admits a different set. Of the 41 catalogued composite pairs, at the catalogue defaults (the pair's own key operations, default KDF):

Template Hybrid required Level floor Composite pairs admitted
DEFAULT No None 41
NIST_HYBRID_OPTIONAL No L1 26
EU_UNIFIED_HYBRID Yes L3 15
ENISA_RISK_BASED No L3 12
ANSSI_HYBRID_ENFORCED Yes L3 12
ETSI_HYBRID_ENFORCED Yes L3 11 (key establishment only)
BSI_HYBRID_ENFORCED Yes L3 4 (the L3/L5 Brainpool pairs)

EU_UNIFIED_HYBRID admits an algorithm or pair that carries any one of BSI, ANSSI or ETSI, so it is broader than each national template, not stricter. The pair lists are in Compliance Region Configuration*.

Feature Comparison

Feature BSI ANSSI ETSI EU_UNIFIED NIST ENISA
Standalone PQC blocked ✅ ✅ ✅ ✅ ❌ ❌
Hash-based exception ✅ ✅ ✅ ✅ ✅ ✅
Min Level 3 ✅ ✅ ✅ ✅ ❌ ✅
HKDF-SHA256 ✅ ✅ ✅ ✅ ✅ ✅
CatKDF ✅ ✅ ✅ ✅ ❌ ✅
CasKDF ❌ ✅ ✅ ✅ ❌ ✅
HKDF-SHA384 / HKDF-SHA512 ❌ ❌ ❌ ❌ ❌ ❌
COMPOSITE_SIGNATURE mode ✅ ✅ ❌ ✅ ✅ ✅
FALCON family ❌ ❌ ❌ ❌ ❌ ❌
HQC family ❌ ❌ ✅ ❌ ❌ ❌
OKP (X25519, X448, Ed25519, Ed448) and OKP pairs ❌ ❌ ✅ ✅ ✅ ❌

No hybrid template above declares FALCON: FALCON-1024 carries ANSSI alone, and no catalogued composite has a FALCON component, so under the ANSSI hybrid mandate it has no reachable form. ANSSI_COMPLIANT, which carries no hybrid mandate, admits FALCON-1024 standalone. HQC carries ETSI and NIST, and only ETSI_HYBRID_ENFORCED declares it. No OKP algorithm or OKP pair carries BSI, ANSSI or ENISA; where OKP is declared, the level floor and the pair's own attribution still decide (ETSI_HYBRID_ENFORCED admits the X448 KEM pairs and Ed448; EU_UNIFIED_HYBRID admits the X448 KEM pairs and Ed448+ML-DSA-87).


Use Case Examples

Use Case 1: German Government Agency

Requirements:

  • Compliance with BSI TR-02102-1
  • Minimum 192-bit security
  • Hybrid keys for quantum resistance

Recommended Template: BSI_HYBRID_ENFORCED

Configuration:

PUT /api/v3/admin/tenants/{tenantId}/policies/algorithm-availability
{"templateName": "BSI_HYBRID_ENFORCED"}

What Users Can Do:

  • ✅ Generate brainpoolP384r1+ML-KEM-1024 with HKDF-SHA256 or CatKDF
  • ✅ Generate brainpoolP384r1+ML-DSA-87 or brainpoolP512r1+ML-DSA-87 composite signatures
  • ✅ Generate SLH-DSA at level 3 or 5 standalone (hash-based exception)
  • ❌ Cannot generate a P-curve or OKP pair (no NIST P-curve and no OKP algorithm carries BSI), FALCON or HQC
  • ❌ Cannot generate ML-KEM standalone
  • ❌ Cannot use ML-KEM-512 (Level 1)
  • ❌ Cannot use CasKDF, HKDF-SHA384 or HKDF-SHA512 (BSI TR-02102-1 Table 2.1 recommends CatKDF and the KeyCombine construction only)

Use Case 2: French Nuclear Facility

Requirements:

  • ANSSI RGS v2 compliance
  • Strong hybridization
  • Combiners ANSSI names (CatKDF, CasKDF) or HKDF-SHA256

Recommended Template: ANSSI_HYBRID_ENFORCED

Configuration:

PUT /api/v3/admin/tenants/{tenantId}/policies/algorithm-availability
{"templateName": "ANSSI_HYBRID_ENFORCED"}

What Users Can Do:

  • ✅ Generate P-384+ML-DSA-65 composite signatures
  • ✅ Generate P-384+ML-KEM-768 with HKDF-SHA256, CatKDF or CasKDF
  • ✅ Generate SLH-DSA at level 3 or 5 standalone (hash-based exception)
  • ❌ Cannot use FALCON (no catalogued composite has a FALCON component; ANSSI_COMPLIANT, without a hybrid mandate, admits FALCON-1024 standalone)
  • ❌ Cannot generate an OKP pair (no OKP algorithm carries ANSSI) or an HQC pair
  • ❌ Cannot use HKDF-SHA384 or HKDF-SHA512 (the ANSSI template lists HKDF-SHA256, CatKDF and CasKDF)
  • ❌ Cannot generate standalone ML-KEM or ML-DSA

Use Case 3: EU 5G Network Operator

Requirements:

  • ETSI TS 103 744 compliance
  • Key exchange for network encryption
  • CatKDF/CasKDF support

Recommended Template: ETSI_HYBRID_ENFORCED

Configuration:

PUT /api/v3/admin/tenants/{tenantId}/policies/algorithm-availability
{"templateName": "ETSI_HYBRID_ENFORCED"}

What Users Can Do:

  • ✅ Generate X448+ML-KEM-768 with CatKDF/CasKDF (every X25519 pair is level 1, below the template floor)
  • ✅ Include HQC inside a composite (X448, P-384 or P-521 with HQC-192 or HQC-256)
  • ❌ Cannot use COMPOSITE_SIGNATURE mode (only KEM for telecom)
  • ❌ Cannot generate standalone PQC

Use Case 4: US Startup (Flexible)

Requirements:

  • NIST FIPS compliance
  • Hybrid optional (not mandated)
  • Development flexibility

Recommended Template: NIST_HYBRID_OPTIONAL

Configuration:

PUT /api/v3/admin/tenants/{tenantId}/policies/algorithm-availability
{"templateName": "NIST_HYBRID_OPTIONAL"}

What Users Can Do:

  • ✅ Generate ML-KEM-768 standalone (hybrid not required)
  • ✅ Generate ML-KEM-512 (Level 1 allowed)
  • ✅ Generate composite keys with HKDF-SHA256
  • ✅ Maximum flexibility for development

Template Upgrade Path

Migration Timeline

timeline
    title Policy Strictness Migration Path

    2026 Q1 : DEFAULT
            : No restrictions
            : All algorithms allowed

    2026 Q2 : ENISA_RISK_BASED
            : Hybrid recommended
            : Level 3 minimum

    2026 Q3 : BSI_HYBRID_ENFORCED
            : Hybrid mandatory
            : Level 3 minimum

    2027+ : EU_UNIFIED_HYBRID
          : Hybrid mandatory
          : BSI, ANSSI or ETSI coverage

Gradual Enforcement Strategy

Phase 1: Informational (No Enforcement)

  • Template: DEFAULT
  • Log warnings for non-compliant key generation
  • Educate users on compliance requirements

Phase 2: Soft Enforcement (Recommended)

  • Template: ENISA_RISK_BASED
  • requireComposite = false (hybrid not mandatory)
  • minSecurityLevel = 3 (block weak algorithms)

Phase 3: Full Enforcement

  • Template: BSI_HYBRID_ENFORCED or ANSSI_HYBRID_ENFORCED
  • requireComposite = true (block standalone PQC)
  • Full regulatory compliance

Phase 4: Multi-Regulation

  • Template: EU_UNIFIED_HYBRID
  • Admits what any one of BSI, ANSSI or ETSI covers, under one Level 3 floor and hybrid mandate; a key it admits is not thereby compliant with all three frameworks

Frequently Asked Questions

Can I combine templates?

No. A policy either names a template or states its own criteria. A template-assigned policy takes every criterion from the template, and a minSecurityLevel or minSecurityStrengthBits sent beside templateName is refused with 400. To start from a template and tighten it, write a policy without a template that states the criteria itself. This policy keeps the BSI_HYBRID_ENFORCED criteria and admits CatKDF alone:

PUT /api/v3/admin/tenants/{id}/policies/algorithm-availability
{
  "allowedFamilies": ["ML-KEM", "ML-DSA", "SLH-DSA", "RSA", "EC", "oct"],
  "allowedLevels": ["L3", "L5"],
  "mandatoryStandards": ["BSI"],
  "requireComposite": true,
  "allowedCompositeModes": ["COMPOSITE_KEM_COMBINE", "COMPOSITE_SIGNATURE"],
  "allowedKdfs": ["CatKDF"],
  "minSecurityLevel": 3,
  "regulatoryFramework": "BSI-TR-02102-1"
}

What happens to keys generated before policy change?

Existing keys continue to work normally. Policy enforcement only applies to:

  • New key generation requests
  • Key import operations

Existing keys are NOT affected by policy updates.

Can I disable enforcement temporarily?

Yes, switch to DEFAULT template:

PUT /api/v3/admin/tenants/{id}/policies/algorithm-availability
{"templateName": "DEFAULT"}

Propagation: ~1-2 seconds (Redis sync + cache invalidation)

How do I audit policy compliance?

Check tenant's active policy:

GET /api/v3/admin/tenants/{id}/policies/algorithm-availability

Check all tenants with specific template:

-- PostgreSQL query
SELECT tenant_id, regulatory_framework, min_security_level
FROM tenant_algorithm_policies
WHERE template_name = 'BSI_HYBRID_ENFORCED'
  AND is_active = true;

Next Steps

* restricted content — see higher-tier documentation