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_ENFORCEDorANSSI_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:
Propagation: ~1-2 seconds (Redis sync + cache invalidation)
How do I audit policy compliance?
Check tenant's active policy:
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
- Regulatory Compliance Matrix - Detailed regulation requirements
- Policy Enforcement Guide - Technical implementation details
- Composite Keys Overview* - Hybrid key fundamentals
- Policy Templates Reference* - Complete template catalog