Compliance

FIPS Compliance for Duende IdentityServer

Understanding and implementing Federal Information Processing Standard (FIPS) compliance with Duende IdentityServer

Federal Information Processing Standard (FIPS) Publication 140-2 is a U.S. government standard that defines minimum security requirements for cryptographic modules in information technology products. Organizations in regulated industries, government agencies, and enterprises with strict security requirements often need to ensure their systems meet FIPS compliance.

Understanding FIPS Compliance

FIPS 140-2 compliance ensures that cryptographic operations meet rigorous security standards validated by the National Institute of Standards and Technology (NIST). This is particularly critical for:

  • Government systems - Federal agencies and contractors
  • Healthcare - HIPAA-regulated organizations
  • Financial services - Banking and payment systems
  • Defense contractors - Systems handling classified information
  • Enterprises - Organizations with strict security policies
FIPS compliance is your responsibility. Duende IdentityServer does not provide built-in FIPS enforcement or a configuration option to automatically make your solution FIPS-compliant. There is no toggle switch or configuration profile.

Why IdentityServer Doesn't Enforce FIPS

Duende IdentityServer is designed as a framework that relies on the underlying platform for cryptographic operations. Specifically, IdentityServer:

  • Does not contain its own cryptographic implementations - It delegates to .NET and the OS
  • Uses platform-provided cryptographic primitives - From .NET runtime and operating system
  • Does not restrict algorithm choices - You must configure FIPS-compliant algorithms yourself
  • Cannot validate your complete solution - FIPS compliance requires system-wide configuration

When IdentityServer signs tokens or protects cookies, it uses cryptographic modules provided by:

  • The underlying .NET runtime
  • The operating system's cryptographic libraries

This design ensures better security through well-tested platform implementations, but places the responsibility for FIPS compliance on you.

Your Responsibilities for FIPS Compliance

To build a FIPS-compliant solution with Duende IdentityServer, you are responsible for:

1. Operating System Configuration

Configure your OS for FIPS mode according to platform requirements:

  • Windows: Enable FIPS mode through Group Policy or Registry
  • Linux: Use FIPS-validated kernel and OpenSSL
  • Container Images: Use FIPS-enabled base images

2. Algorithm Selection

Choose only FIPS-validated cryptographic algorithms:

  • Token Signing: Use PS256, PS384, PS512, ES256, ES384, or ES512
  • Avoid: RS256, RS384, RS512 (not FIPS-compliant)
  • Data Protection: Use AES-256-GCM with HMAC-SHA256

3. Key Storage

Store cryptographic keys in FIPS 140-2 validated modules:

  • Hardware Security Modules (HSM)
  • Azure Key Vault with Premium tier (HSM-backed)
  • AWS CloudHSM
  • Other FIPS 140-2 Level 2 or higher validated devices

4. Complete Solution Validation

Validate that your entire solution meets FIPS requirements:

  • Application configuration
  • Runtime environment
  • Key management practices
  • Operational procedures

Implementing FIPS Compliance

Step 1: Configure .NET for FIPS Mode

Enable FIPS mode in your .NET application following Microsoft's guidance:

public static WebApplication ConfigureServices(this WebApplicationBuilder builder)
{
    // Enable FIPS mode
    if (builder.Configuration.GetValue<bool>("FIPS:Enabled", false))
    {
        AppContext.SetSwitch("Switch.System.Security.Cryptography.UseLegacyFipsThrow", false);
        Log.Information("FIPS mode enabled for cryptographic operations");
    }

    // ... rest of your configuration
}
Configuration Best Practice: Use environment-specific configuration files to enable FIPS mode only in production environments where it's required. This allows development flexibility while ensuring production compliance.

Reference: Microsoft .NET FIPS Compliance Documentation

Step 2: Select FIPS-Compliant Signing Algorithms

Configure IdentityServer to use only FIPS-validated algorithms for token signing:

builder.Services.AddIdentityServer(options =>
{
    // FIPS-COMPLIANT SIGNING ALGORITHMS ONLY
    options.KeyManagement.SigningAlgorithms = new[]
    {
        // PS256 - FIPS compliant (RSA-PSS with SHA-256)
        new SigningAlgorithmOptions(SecurityAlgorithms.RsaSsaPssSha256) 
        { 
            UseX509Certificate = true 
        },

        // ES256 - FIPS compliant (ECDSA with P-256 and SHA-256)
        new SigningAlgorithmOptions(SecurityAlgorithms.EcdsaSha256)
    };

    // Additional FIPS-compliant options
    options.KeyManagement.SigningAlgorithms = new[]
    {
        new SigningAlgorithmOptions(SecurityAlgorithms.RsaSsaPssSha256),
        new SigningAlgorithmOptions(SecurityAlgorithms.RsaSsaPssSha384),
        new SigningAlgorithmOptions(SecurityAlgorithms.RsaSsaPssSha512),
        new SigningAlgorithmOptions(SecurityAlgorithms.EcdsaSha256),
        new SigningAlgorithmOptions(SecurityAlgorithms.EcdsaSha384),
        new SigningAlgorithmOptions(SecurityAlgorithms.EcdsaSha512)
    };
});
Critical: Do NOT use RS256, RS384, or RS512. These algorithms (RSA-PKCS1-v1_5 with SHA) are not FIPS-compliant. Use PS* (RSA-PSS) or ES* (ECDSA) algorithms instead.

Algorithms Comparison

AlgorithmFIPS CompliantIdentityServer SupportRecommended
RS256❌ No✅ Yes❌ Do not use
RS384❌ No✅ Yes❌ Do not use
RS512❌ No✅ Yes❌ Do not use
PS256✅ Yes✅ Yes✅ Recommended
PS384✅ Yes✅ Yes✅ Recommended
PS512✅ Yes✅ Yes✅ Recommended
ES256✅ Yes✅ Yes✅ Recommended
ES384✅ Yes✅ Yes✅ Recommended
ES512✅ Yes✅ Yes✅ Recommended

Step 3: Configure FIPS-Compliant Client Authentication

Ensure all client authentication methods use FIPS-compliant algorithms:

builder.Services.AddIdentityServer(options =>
{
    // DPoP (Demonstrating Proof-of-Possession) algorithms
    options.DPoP.SupportedDPoPSigningAlgorithms = [
        SecurityAlgorithms.RsaSsaPssSha256,
        SecurityAlgorithms.RsaSsaPssSha384,
        SecurityAlgorithms.RsaSsaPssSha512,
        SecurityAlgorithms.EcdsaSha256,
        SecurityAlgorithms.EcdsaSha384,
        SecurityAlgorithms.EcdsaSha512
    ];

    // Client Assertion (JWT Bearer) algorithms
    options.SupportedClientAssertionSigningAlgorithms = [
        SecurityAlgorithms.RsaSsaPssSha256,
        SecurityAlgorithms.RsaSsaPssSha384,
        SecurityAlgorithms.RsaSsaPssSha512,
        SecurityAlgorithms.EcdsaSha256,
        SecurityAlgorithms.EcdsaSha384,
        SecurityAlgorithms.EcdsaSha512
    ];

    // Request Object (JAR - JWT Secured Authorization Request) algorithms
    options.SupportedRequestObjectSigningAlgorithms = [
        SecurityAlgorithms.RsaSsaPssSha256,
        SecurityAlgorithms.RsaSsaPssSha384,
        SecurityAlgorithms.RsaSsaPssSha512,
        SecurityAlgorithms.EcdsaSha256,
        SecurityAlgorithms.EcdsaSha384,
        SecurityAlgorithms.EcdsaSha512
    ];
});

Step 4: Configure FIPS-Compliant Data Protection

ASP.NET Core Data Protection must also use FIPS-compliant algorithms:

using Microsoft.AspNetCore.DataProtection;
using Microsoft.AspNetCore.DataProtection.AuthenticatedEncryption;
using Microsoft.AspNetCore.DataProtection.AuthenticatedEncryption.ConfigurationModel;

// Configure Data Protection with FIPS-compliant algorithms
builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo("/app/dp-keys"))
    .UseCryptographicAlgorithms(new AuthenticatedEncryptorConfiguration
    {
        EncryptionAlgorithm = EncryptionAlgorithm.AES_256_GCM,
        ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
    });
Key Persistence: In Kubernetes environments, ensure keys are stored on persistent volumes to survive pod restarts. Consider using Azure Key Vault or AWS KMS for production environments.

Step 5: Use FIPS-Validated Key Storage

For production environments, use FIPS 140-2 validated hardware security modules:

Azure Key Vault Integration

using Azure.Identity;
using Azure.Security.KeyVault.Certificates;

builder.Services.AddIdentityServer(options =>
{
    // ... other options
})
.AddSigningCredential(async () => 
{
    var client = new CertificateClient(
        new Uri("https://your-keyvault.vault.azure.net/"),
        new DefaultAzureCredential());
    
    var certificate = await client.GetCertificateAsync("signing-cert");
    return certificate.Value;
});

AWS CloudHSM Integration

Use AWS CloudHSM PKCS#11 provider with IdentityServer for FIPS 140-2 Level 3 compliance.

Premium Tier Required: Azure Key Vault's Premium tier uses FIPS 140-2 Level 2 validated HSMs. The Standard tier does not provide FIPS-validated protection.

FIPS Compliance in Kubernetes

Deploying IdentityServer in Kubernetes requires additional configuration for FIPS compliance.

Container Image Requirements

Use FIPS-enabled base images:

# Use FIPS-compliant base image
FROM mcr.microsoft.com/dotnet/aspnet:8.0-cbl-mariner2.0

WORKDIR /app

# Create directories for key storage
RUN mkdir -p /app/keys /app/dp-keys && \
    chmod 700 /app/keys /app/dp-keys

COPY ./publish .

ENTRYPOINT ["dotnet", "YourIdentityServer.dll"]
CBL-Mariner: Microsoft's CBL-Mariner (Common Base Linux) 2.0 images include FIPS-validated OpenSSL and kernel components, making them suitable for FIPS-compliant deployments.

Kubernetes Deployment Configuration

Configure persistent storage and environment variables:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: identityserver-keys
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile  # or your storage class
  resources:
    requests:
      storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: identityserver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: identityserver
  template:
    metadata:
      labels:
        app: identityserver
    spec:
      containers:
      - name: identityserver
        image: your-registry/identityserver:fips
        env:
        - name: ASPNETCORE_ENVIRONMENT
          value: "Production"
        - name: FIPS__Enabled
          value: "true"
        - name: KeyManagement__KeyPath
          value: "/app/keys"
        - name: DataProtection__KeyPath
          value: "/app/dp-keys"
        volumeMounts:
        - name: keys
          mountPath: /app/keys
        - name: dp-keys
          mountPath: /app/dp-keys
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
      volumes:
      - name: keys
        persistentVolumeClaim:
          claimName: identityserver-keys
      - name: dp-keys
        persistentVolumeClaim:
          claimName: identityserver-keys

Azure Workload Identity for Key Vault

Use Azure Workload Identity to access Key Vault from Kubernetes:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: identityserver-sa
  annotations:
    azure.workload.identity/client-id: "<your-managed-identity-client-id>"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: identityserver
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: identityserver-sa
      # ... rest of deployment spec

Configuration Best Practices

Environment-Specific Configuration

Use appsettings.Production.json for FIPS-specific settings:

{
  "FIPS": {
    "Enabled": true
  },
  "KeyManagement": {
    "KeyPath": "/app/keys",
    "RotationInterval": "3.00:00:00",
    "PropagationTime": "1.00:00:00",
    "RetentionDuration": "7.00:00:00"
  },
  "DataProtection": {
    "KeyPath": "/app/dp-keys"
  }
}

Key Management Configuration

Configure appropriate key rotation and retention:

builder.Services.AddIdentityServer(options =>
{
    // Rotate signing keys every 3 days
    options.KeyManagement.RotationInterval = TimeSpan.FromDays(3);
    
    // Announce new key 1 day in advance in discovery
    options.KeyManagement.PropagationTime = TimeSpan.FromDays(1);
    
    // Keep old key for 7 days for token validation
    options.KeyManagement.RetentionDuration = TimeSpan.FromDays(7);
    
    // Use persistent storage path
    var keyPath = builder.Configuration.GetValue<string>("KeyManagement:KeyPath") 
                  ?? "/app/keys";
    options.KeyManagement.KeyPath = keyPath;
});
RotationInterval must be longer than PropagationTime. Ensure new keys are propagated before old keys are rotated out to prevent token validation failures.

Validation and Testing

Health Check Endpoint

Implement a health check to verify FIPS mode is enabled:

app.MapGet("/health/fips", () =>
{
    var isFipsEnabled = AppContext.TryGetSwitch(
        "Switch.System.Security.Cryptography.UseLegacyFipsThrow", 
        out var enabled) && !enabled;
    
    return Results.Ok(new 
    { 
        fipsMode = isFipsEnabled,
        signingAlgorithms = new[] { "PS256", "ES256", "PS384", "ES384", "PS512", "ES512" },
        environment = app.Environment.EnvironmentName
    });
}).AllowAnonymous();

Discovery Endpoint Verification

Verify the discovery endpoint only advertises FIPS-compliant algorithms:

# Check discovery endpoint
curl https://your-identityserver.com/.well-known/openid-configuration | jq .id_token_signing_alg_values_supported

# Expected output (FIPS-compliant):
# ["PS256", "ES256", "PS384", "ES384", "PS512", "ES512"]

# Should NOT include:
# ["RS256", "RS384", "RS512"]

Testing Checklist

  • FIPS mode enabled in .NET runtime
  • Only PS* and ES* algorithms configured
  • Discovery endpoint shows correct algorithms
  • Data Protection uses FIPS-compliant algorithms
  • Keys stored in FIPS-validated HSM (production)
  • Container base image is FIPS-compliant
  • All client authentication methods are FIPS-compliant
  • Token validation uses only FIPS algorithms

Client Compatibility Considerations

When migrating to FIPS-compliant algorithms, consider client compatibility:

Algorithm Migration Strategy

If you currently use RS256 and need to migrate:

  1. Add FIPS algorithms alongside existing ones temporarily
  2. Update clients to support PS256 or ES256
  3. Monitor which clients still use RS256
  4. Remove RS256 after all clients are updated
// Transition period (NOT FIPS-compliant, but allows migration)
options.KeyManagement.SigningAlgorithms = new[]
{
    new SigningAlgorithmOptions(SecurityAlgorithms.RsaSsaPssSha256),
    new SigningAlgorithmOptions(SecurityAlgorithms.EcdsaSha256),
    new SigningAlgorithmOptions(SecurityAlgorithms.RsaSha256) // Remove after migration
};
During Transition: Your system is NOT FIPS-compliant while RS256 is still configured. Remove it as soon as all clients are updated.

Client Library Support

Most modern OAuth 2.0 client libraries support PS256 and ES256:

LibraryPS256 SupportES256 Support
IdentityModel (C#)✅ Yes✅ Yes
MSAL (Microsoft)✅ Yes✅ Yes
AppAuth (iOS/Android)✅ Yes✅ Yes
Passport.js (Node)✅ Yes✅ Yes
Spring Security✅ Yes✅ Yes

Common Issues and Solutions

Issue: Old Keys Still Using RS256

Problem: After configuration change, old signing keys still use RS256.

Solution:

  • Wait for key retention period to expire (default: 7 days)
  • Or manually delete old keys from the key storage directory
  • Or reduce RetentionDuration temporarily during migration

Issue: Client Token Validation Fails

Problem: Clients fail to validate tokens with PS256/ES256.

Solution:

  • Verify client library supports PS256/ES256
  • Update client configuration to accept new algorithms
  • Check client's algorithm whitelist configuration

Issue: Data Protection Keys Not Persisting

Problem: Application loses session state after pod restart.

Solution:

  • Verify PersistentVolumeClaim is mounted correctly
  • Check file permissions on key directories
  • Ensure storage class supports ReadWriteMany for multiple pods

Issue: Azure Key Vault Access Denied

Problem: IdentityServer cannot access certificates in Key Vault.

Solution:

  • Verify Managed Identity has correct permissions
  • Check Key Vault access policies or RBAC roles
  • Ensure Workload Identity is configured correctly
  • Verify network connectivity to Key Vault

Security Considerations

Defense in Depth

FIPS compliance is one layer of security. Also implement:

  • Network Security: Use TLS 1.2+ with FIPS-compliant cipher suites
  • Access Control: Implement proper authentication and authorization
  • Audit Logging: Log all cryptographic operations
  • Incident Response: Have procedures for key compromise
  • Regular Updates: Keep .NET runtime and OS patched

Cipher Suite Configuration

Configure TLS to use only FIPS-compliant cipher suites:

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ConfigureHttpsDefaults(httpsOptions =>
    {
        httpsOptions.SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13;
        // Additional FIPS-compliant TLS configuration
    });
});

Key Rotation Policy

Establish and document key rotation procedures:

  • Automatic Rotation: Use IdentityServer's built-in key management
  • Emergency Rotation: Procedures for suspected key compromise
  • Backup and Recovery: Secure backup of key material
  • Access Auditing: Log all access to key material

Compliance Documentation

Maintain documentation for compliance audits:

Required Documentation

  1. Architecture Diagrams showing cryptographic boundaries
  2. Algorithm Selection justification and approval
  3. Key Management Procedures including rotation and storage
  4. System Configuration with FIPS settings highlighted
  5. Test Results demonstrating FIPS compliance
  6. Incident Response procedures for key compromise

Audit Trail

Implement comprehensive logging:

builder.Services.AddIdentityServer(options =>
{
    // Enable comprehensive event logging
    options.Events.RaiseErrorEvents = true;
    options.Events.RaiseInformationEvents = true;
    options.Events.RaiseFailureEvents = true;
    options.Events.RaiseSuccessEvents = true;
});

Implementation Resources

FIPS 140-2 Standard

Official NIST FIPS 140-2 specification

.NET FIPS Compliance

Microsoft documentation on .NET Core FIPS compliance

Duende IdentityServer

Official Duende FIPS compliance documentation

Azure Key Vault

Azure Key Vault FIPS 140-2 validated HSM

AWS CloudHSM

AWS CloudHSM for FIPS 140-2 Level 3 compliance

NIST Cryptographic Standards

NIST cryptographic algorithm validation program

CBL-Mariner

Microsoft's FIPS-compliant Linux distribution

Azure Workload Identity

Kubernetes integration with Azure Key Vault

Post-Quantum Cryptography in .NET

Community discussion on PQC support in .NET 10

NIST Post-Quantum Cryptography

NIST PQC standardization project and selected algorithms

Future Considerations: Post-Quantum Cryptography

As quantum computing advances, cryptographic algorithms face new challenges. The cryptographic community is preparing for this transition:

Post-Quantum Cryptography Timeline

  • NIST Standardization: NIST has selected post-quantum cryptographic algorithms (CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+)
  • .NET 10 Support: Microsoft is adding post-quantum cryptography support in .NET 10
  • Hybrid Approaches: Combining classical (RSA/ECDSA) with post-quantum algorithms for defense in depth
Community Discussion: For insights on post-quantum cryptography in .NET, see maartenba's discussion on Post-Quantum Cryptography in .NET 10 (November 19, 2025). This includes implementation details and migration strategies.

Preparing for Post-Quantum Transition

While FIPS 140-2 currently validates classical algorithms, organizations should:

  1. Monitor NIST Standards: Track NIST Post-Quantum Cryptography standardization
  2. Plan Migration: Develop strategies for algorithm migration
  3. Hybrid Cryptography: Consider using both classical and post-quantum algorithms during transition
  4. Key Agility: Ensure your architecture supports algorithm changes without major rewrites

FIPS 140-3 and Beyond

NIST is updating to FIPS 140-3, which will eventually include post-quantum algorithms:

  • FIPS 140-3: Published in 2019, already replacing FIPS 140-2
  • PQC Integration: Future versions will validate post-quantum algorithms
  • Timeline: Post-quantum algorithms expected in FIPS modules by 2030-2035
Long-Term Planning: While implementing FIPS 140-2 compliance today, design your system with algorithm agility to support future post-quantum algorithms without major architectural changes.

Key Takeaways

When implementing FIPS compliance with Duende IdentityServer:

  1. FIPS compliance is your responsibility - IdentityServer provides the framework, you configure it
  2. Use only FIPS-compliant algorithms - PS256, PS384, PS512, ES256, ES384, ES512
  3. Never use RS256, RS384, or RS512 - These are not FIPS-compliant
  4. Configure the entire stack - OS, .NET runtime, IdentityServer, and Data Protection
  5. Use FIPS-validated key storage - HSMs or cloud-based validated services
  6. Test thoroughly - Verify algorithms at discovery endpoint and runtime
  7. Plan client migration - Ensure all clients support FIPS-compliant algorithms
  8. Document everything - Maintain compliance documentation for audits
  9. Implement defense in depth - FIPS is one layer of security, not the only one
  10. Validate your complete solution - You must validate the entire system meets FIPS requirements
  11. Design for algorithm agility - Prepare for future transitions including post-quantum cryptography