Migration & Interoperability - Overview

Purpose: Strategic foundation for the Frictionless Modernization pillar of AnkaSecure

Version: 3.0.0

The Five Pillars of Effective Modern Cryptography

ANKASecure is built on five fundamental pillars that work together to create a future-proof cryptographic posture—secure, sovereign, and agile:

graph TB
    subgraph Temple[" "]
        Roof["Future-Proof Cryptographic Posture<br/>Secure, Sovereign, and Agile"]

        Pillar1["Pillar 1<br/>Crypto-Agility<br/>Quick adaptation to<br/>threats and algorithm evolution"]

        Pillar2["Pillar 2<br/>Cryptographic Sovereignty<br/>Control over keys and<br/>cryptographic operations"]

        Pillar3["Pillar 3<br/>Frictionless Modernization<br/>Add PQC to existing<br/>systems without redesign"]

        Pillar4["Pillar 4<br/>Cryptographic Governance<br/>&amp; Compliance<br/>Central policy, evidence,<br/>instant propagation"]

        Pillar5["Pillar 5<br/>Enterprise Readiness<br/>Your HSM/KMS, IdP, SIEM<br/>and observability backend"]

        Foundation["These 5 pillars support a future-proof cryptographic posture<br/>One platform delivering all 5 pillars"]
    end

    Roof -.->|Supported by| Pillar1
    Roof -.->|Supported by| Pillar2
    Roof -.->|Supported by| Pillar3
    Roof -.->|Supported by| Pillar4
    Roof -.->|Supported by| Pillar5

    Pillar1 -.->|Built on| Foundation
    Pillar2 -.->|Built on| Foundation
    Pillar3 -.->|Built on| Foundation
    Pillar4 -.->|Built on| Foundation
    Pillar5 -.->|Built on| Foundation

    style Roof fill:#f5f5f5,stroke:#333,stroke-width:4px
    style Pillar1 fill:#ff9933,stroke:#333,stroke-width:2px,color:#000
    style Pillar2 fill:#3399ff,stroke:#333,stroke-width:2px,color:#000
    style Pillar3 fill:#33cc66,stroke:#333,stroke-width:2px,color:#000
    style Pillar4 fill:#ff6b6b,stroke:#333,stroke-width:2px,color:#000
    style Pillar5 fill:#9b59b6,stroke:#333,stroke-width:2px,color:#000
    style Foundation fill:#f5f5f5,stroke:#333,stroke-width:4px

Pillar 1: Crypto-agility (Quick Adaptation)

Definition: The ability to adapt, change, or update cryptographic algorithms without modifying application infrastructure.

Key Capabilities:

• Algorithm transitions without code changes
• keyIds remain constant during migrations
• Configuration-driven algorithm updates
• Immediate regulatory compliance

Migration Relevance: Crypto-agility enables seamless transitions from classical to post-quantum algorithms, supporting both during migration periods.

Pillar 2: Cryptographic Sovereignty (Control)

Definition: Complete control over cryptographic keys and operations, independent of third-party dependencies.

Key Capabilities:

• Full key lifecycle management
• Tenant-isolated keystores
• HSM envelope encryption
• No vendor lock-in for cryptographic operations

Migration Relevance: Organizations maintain complete control over legacy keys during import, analysis, and conversion phases, ensuring data sovereignty throughout the modernization process.

Pillar 3: Frictionless Modernization (Seamless Migration)

Definition: Add post-quantum cryptography to existing systems without redesigning applications or infrastructure.

Key Capabilities:

• Import from legacy systems (PKCS#12, X.509 certificates)
• Analyze cryptographic compatibility
• Convert encrypted data and signatures
• Bridge patterns for interoperability

Migration Relevance: THIS SECTION - Complete workflow from legacy cryptography to post-quantum readiness.

Pillar 4: Cryptographic Governance & Compliance (Centralized, Context-Aware, Evidenced)

Definition: Centralized policy management with instant propagation across all cryptographic operations.

Key Capabilities:

• 29 algorithm-availability templates
• <1 second policy propagation
• Algorithm availability enforcement
• Key lifecycle policy management

Migration Relevance: During migration, policies ensure that only approved algorithms are used, preventing accidental downgrades and maintaining compliance throughout the transition process.

Pillar 5: Enterprise Readiness (Migrate Without Replacing Your Platforms)

Definition: the platform operates as a native component of the enterprise's existing technology environment rather than as another silo.

Key Capabilities:

• The customer's own HSM or cloud KMS remains the Root of Trust for the KEK, through a three-rung precedence (tenant BYOK → edition-assigned → deployment)
• Human access federates against the enterprise identity provider (OIDC, SAML, LDAP); machine workloads authenticate with the token their own platform already issues
• Signed audit events are forwarded to the enterprise SIEM/XDR in CEF or OCSF, with the signature preserved for independent verification
• Traces and metrics export over OTLP to the observability backend already in use
• External interoperability — JOSE output standard libraries can verify, PKCS#7 input, caller-supplied public keys — without redefining the internal posture

Migration Relevance: a migration does not begin with a consolidation project. The estate keeps its custody backend, its directory, its SIEM and its dashboards, and the cryptographic layer joins them. Regulatory alignment belongs to Pillar 4, which carries governance and compliance together.

Why Migration Matters

The Quantum Timeline Pressure

The transition to post-quantum cryptography is not optional—it's a regulatory and security imperative:

Regulatory Milestones:

• 2024: NIST publishes final PQC standards (ML-KEM, ML-DSA, SLH-DSA)
• 2025: White House Executive Order 14144 on post-quantum cryptography
• 2030: NSA deadline (CNSA 2.0) for mandatory migration to quantum-resistant algorithms
• Ongoing: Active PQC strategies in Canada, EU, Germany, and other jurisdictions

Security Reality:

• Harvest-now-decrypt-later attacks: Encrypted data captured today can be decrypted by future quantum computers
• Cryptographically relevant quantum computers estimated within 10-15 years
• Long-lived data (financial records, medical data, government documents) needs protection now

The Cost of Inaction vs. ANKASecure

Traditional migration approaches are prohibitively expensive and risky:

Scenario: Enterprise with 200 Applications

Traditional Migration (without ANKASecure):

Time to production: 6-12 months
Risk level: Extremely high Inconsistency risk: Inevitable across applications

Migration with ANKASecure:

Time to production: Same day
Risk level: Minimal (centralized control) Consistency: Guaranteed (single point of truth)

Cost Reduction: 99.99% (from $840K to $30)

Migration Capabilities Overview

ANKASecure provides comprehensive migration capabilities organized around four core operations:

graph LR
    Legacy["Legacy System<br/>RSA, ECDSA, etc."]
    Import["Import<br/>PKCS#12, Certificates, Keys"]
    Analyze["Analyze<br/>Validate Compatibility"]
    Convert["Convert<br/>Re-encrypt, Re-sign, Transform"]
    PQC["PQC System<br/>ML-KEM, ML-DSA, etc."]
    Bridge["Interoperability<br/>Bridge Pattern, Utility Ops"]

    Legacy -->|1. Import Keys| Import
    Import -->|2. Validate| Analyze
    Analyze -->|3. Transform| Convert
    Convert -->|4. Migrate Data| PQC
    Legacy -.->|Alternative: No Persistence| Bridge
    Bridge -.->|Stateless Operations| PQC

    style Legacy fill:#ffcccc,stroke:#333,stroke-width:2px
    style Import fill:#4dabf7,stroke:#333,stroke-width:2px
    style Analyze fill:#ffd43b,stroke:#333,stroke-width:2px
    style Convert fill:#a9e34b,stroke:#333,stroke-width:2px
    style PQC fill:#51cf66,stroke:#333,stroke-width:2px
    style Bridge fill:#a9e34b,stroke:#333,stroke-dasharray: 5 5

1. Import Operations

Purpose: Bring cryptographic material from legacy systems into ANKASecure's managed environment.

Capabilities:

• PKCS#12 import: Import private keys and certificate chains from .p12/.pfx keystores
• Multi-key handling: Automatic kid generation for PKCS#12 files with multiple keys
• Certificate validation: 7-stage validation pipeline with configurable modes (STRICT, IMPORT_ONLY, SKIP)
• Trust anchor validation: RFC 5280 PKIX certification path validation
• HSM protection: All imported keys wrapped with HSM KEK for security

Use Cases:

• Migrating from legacy CAs (VeriSign, DigiCert, internal PKI)
• Importing existing TLS/SSL certificates
• Consolidating keys from multiple legacy systems
• Recovering keys from backup keystores

See: import is a control-plane operation on the Admin API, POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore; the step-by-step import procedure is delivered with a licensed deployment.

2. Analyze Operations

Purpose: Validate and assess imported cryptographic material before conversion.

Capabilities:

• Certificate validation: X.509 structure, key binding, temporal validity, chain verification
• Compatibility analysis: Algorithm identification, key size verification, PQC migration path mapping
• Security analysis: Expiration assessment, weakness detection, compliance checking
• Status determination: the certificate's temporal and revocation state, and the operation restrictions it implies. A key imported from it then carries one of the nine published key-status tokens (active, pending_rotation, rotated, expired, revoked, archived, deleted_logical, suspended, pending_destruction) — a different, larger vocabulary than a certificate's own state

Use Cases:

• Pre-conversion validation of imported keys
• Understanding certificate expiration impact on operations
• Determining migration path from classical to PQC algorithms
• Compliance assessment against organizational policies

See: Analyze Operations

3. Convert Operations

Purpose: Transform legacy cryptographic material and data to post-quantum equivalents.

Capabilities:

• Data re-encryption: Decrypt with legacy keys, re-encrypt with PQC keys
• Signature conversion: Verify legacy signatures, re-sign with PQC algorithms
• Streaming re-encryption: Large file conversion without plaintext exposure (USPTO patent 2025)
• Batch operations: Bulk conversion with checkpoint/resume patterns
• Hybrid crypto: Support dual-algorithm signatures during transition periods

Use Cases:

• Migrating encrypted archives from RSA to ML-KEM
• Re-signing documents from RSA to ML-DSA
• Converting TLS certificates from ECDSA to FALCON
• Bulk data transformation for compliance deadlines

See: Convert Operations

4. Interoperability (Bridge Pattern)

Purpose: Enable stateless cryptographic operations with external keys without persistence.

Capabilities:

• Stateless verification: Verify JWS signatures with caller-supplied public keys
• Stateless encryption: Encrypt with external public keys without storing them
• Zero keystore pollution: No persistence overhead for one-time operations
• Immediate interoperability: Work with external systems managing their own keys

Use Cases:

• Verifying signatures from external partners
• Testing encryption compatibility before full integration
• One-time cryptographic operations
• Proof-of-concept evaluations

See: Utility Operations

Migration Architecture

The migration subsystem within ANKASecure Core API provides specialized endpoints for each operation type:

graph TB
    subgraph Client["Client / External System"]
        LEGACY["Legacy System<br/>PKCS#12, X.509"]
        EXTKEY["External Keys<br/>DER/PEM"]
    end

    subgraph MigrationController["/api/migration - MigrationController"]
        EP1["POST /keystores<br/>Import PKCS#12/JKS"]
        EP2["POST /api/v3/interoperability/verify<br/>Verify with External Key"]
        EP3["POST /api/v3/interoperability/encrypt<br/>Encrypt with External Key"]
        EP4["GET /keys/:kid<br/>Export Key"]
    end

    subgraph CoreServices["ANKASecure Core Services"]
        VALIDATOR["X509CertificateValidator<br/>7-stage validation pipeline"]
        KEYSTORE["(Keystore<br/>Tenant-isolated<br/>HSM-protected)"]
        LIFECYCLE["KeyLifecycleService<br/>Policy enforcement"]
        CRYPTO["CryptoEngine<br/>PQC operations"]
    end

    LEGACY -->|Import| EP1
    EP1 -->|Validate| VALIDATOR
    EP1 -->|Store| KEYSTORE

    EXTKEY -->|Verify| EP2
    EP2 -.->|Stateless<br/>NOT persisted| VALIDATOR

    EXTKEY -->|Encrypt| EP3
    EP3 -.->|Stateless<br/>NOT persisted| CRYPTO

    Client -->|Export| EP4
    EP4 -->|Query| KEYSTORE
    KEYSTORE -->|Enforce policy| LIFECYCLE

    style EP1 fill:#4dabf7,stroke:#333,stroke-width:2px
    style EP2 fill:#a9e34b,stroke:#333,stroke-width:2px
    style EP3 fill:#a9e34b,stroke:#333,stroke-width:2px
    style EP4 fill:#ffd43b,stroke:#333,stroke-width:2px
    style VALIDATOR fill:#51cf66,stroke:#333,stroke-width:2px
    style KEYSTORE fill:#ff6b6b,stroke:#333,stroke-width:2px

Key Design Principles:

1. Migration endpoints are NOT part of regular operations: They exist exclusively for migration and interoperability scenarios
2. Stateless utility operations: External key operations don't persist keys in ANKASecure's keystore
3. Multi-stage validation: Certificate and key validation through a comprehensive 7-stage pipeline
4. Policy-driven lifecycle: Imported keys subject to same lifecycle policies as native keys
5. Tenant isolation: All imported keys isolated per tenant with HSM envelope encryption

Migration Approaches

Organizations can choose from three primary migration strategies based on their risk tolerance, timeline, and operational constraints:

Approach 1: Phased Migration (Recommended)

Description: Gradual transition from legacy to PQC cryptography in controlled phases.

Timeline: 2-6 months depending on scale

Process:

1. Import legacy keys (allow decryption of historical data)
2. Decrypt legacy data using imported keys
3. Re-encrypt with PQC keys (ML-KEM, ML-DSA)
4. Retire imported keys after data migration complete

Advantages:

• ✅ Lowest risk (rollback at any phase)
• ✅ Continuous validation (verify each phase before proceeding)
• ✅ Minimal disruption (applications continue operating)
• ✅ Learning opportunity (team gains experience incrementally)

Disadvantages:

• ⏱️ Longer timeline (months vs. days)
• 📊 More coordination (multiple deployment phases)

Best For: Enterprises with 100+ applications, high-security requirements, regulated industries

See: Complete Enterprise Migration^*

Approach 2: Parallel Operation (Hybrid Crypto)

Description: Run legacy and PQC cryptography simultaneously during a transition period.

Timeline: 1-3 months

Process:

1. Import legacy keys (maintain historical operations)
2. Generate PQC keys (prepare new operations)
3. Dual-signature/encryption period (both algorithms active)
4. Gradual cutover (shift traffic from legacy to PQC)
5. Legacy retirement (sunset classical cryptography)

Advantages:

• ✅ Zero downtime (seamless transition)
• ✅ Validation window (compare legacy vs. PQC results)
• ✅ Rollback capability (revert if issues detected)
• ✅ Gradual confidence building

Disadvantages:

• 💾 Higher resource usage (double cryptographic operations)
• 🔍 Complex monitoring (track both algorithm families)

Best For: Mission-critical systems, zero-tolerance for downtime, financial services

See: RSA to ML-KEM Migration, RSA to ML-DSA Migration

Approach 3: Big Bang Migration

Description: Complete cutover from legacy to PQC in a single event.

Timeline: Days to 2 weeks

Process:

1. Import all legacy keys (preparation phase)
2. Analyze compatibility (validate migration path)
3. Convert all data (batch re-encryption/re-signing)
4. Cutover (switch to PQC operations)
5. Verification (post-cutover validation)

Advantages:

• ⚡ Fastest timeline (complete within weeks)
• 💰 Lowest operational cost (single effort)
• 🎯 Clear success criteria (binary outcome)

Disadvantages:

• ⚠️ Higher risk (less validation checkpoints)
• 🔄 Complex rollback (requires full reversion)
• 📅 Requires maintenance window (potential downtime)

Best For: Small to medium deployments (<50 apps), greenfield projects, PoC/pilot programs

Decision Framework: Choosing Your Migration Approach

Use this decision tree to select the appropriate migration approach:

graph TD
    Start{"Application Count?"}
    Start -->|< 50 apps| Timeline1{"Timeline Constraint?"}
    Start -->|50-200 apps| RiskTolerance{"Risk Tolerance?"}
    Start -->|200+ apps| Phased["Phased Migration<br/>2-6 months"]

    Timeline1 -->|< 2 weeks| BigBang["Big Bang Migration<br/>Days to 2 weeks"]
    Timeline1 -->|Flexible| Parallel1["Parallel Operation<br/>1-3 months"]

    RiskTolerance -->|Low: Zero downtime| Parallel2["Parallel Operation<br/>1-3 months"]
    RiskTolerance -->|Medium: Acceptable downtime| Mixed{"Validate in stages?"}

    Mixed -->|Yes| Phased
    Mixed -->|No| BigBang

    style Phased fill:#51cf66,stroke:#333,stroke-width:2px
    style Parallel1 fill:#4dabf7,stroke:#333,stroke-width:2px
    style Parallel2 fill:#4dabf7,stroke:#333,stroke-width:2px
    style BigBang fill:#ffd43b,stroke:#333,stroke-width:2px

Legacy Format Migration

For organizations with legacy PKCS#7/CMS files (S/MIME, legacy systems):

Migration path: Import → Analyze → Convert → (Optional) PQC Re-encrypt

Step 1: Import Keys

• Import PKCS#12/JKS keystores holding, with its private key, a key for every actor: each signer (admissible to sign), the recipient that decrypts (admissible to decrypt and encrypt), and every other recipient (admissible to encrypt — a keystore import with its private key, or the encryption key of a DUAL import)
• Current limitation: a certificate imported alone is a verify-only trust anchor and is refused as a signer or a recipient
• Endpoint: POST /api/v3/admin/tenants/{tenantId}/keys/import-keystore
• Validation modes: STRICT, IMPORT_ONLY (for expired certs), SKIP. Current limitation: a key IMPORT_ONLY imports with an expired certificate or a failed chain is restricted (read-only) and the conversion refuses it
• Output: Keys the conversion matches to the file's actors by issuer DN and serial number

Step 2: Analyze PKCS#7 Files

• Understand structure, algorithms, and conversion feasibility
• Endpoint: POST /api/v3/migration/analyze-pkcs7 (compact or streaming)
• Output: Metadata, support status, recommendations

Step 3: Convert to JOSE Format

• Transform PKCS#7 container to modern JWE/JWS with the same keys: the content is re-signed and re-encrypted, not translated
• Endpoint: POST /api/v3/migration/convert-pkcs7-to-jose (compact or streaming)
• Authorization: the migration.convertPkcs7 scope plus Capability Grants on the imported keys — REENCRYPT from the decrypting recipient to every recipient (N-1 pair grants [decrypting recipient, recipient] for N recipients; one recipient needs the in-place grant, requested as assetKids: [kid, kid] and stored as [kid]) and RESIGN from each signer to itself ([signer, signer]). There is no wildcard REENCRYPT or RESIGN grant. DECRYPT, ENCRYPT and SIGN grants do not authorize a conversion
• Output: JWE/JWS tokens with classical algorithms — PS256/ES* signatures, RSA-OAEP-512 key management, A256GCM content encryption — carrying every signer and every recipient: the Compact serialization for at most one signer and at most one recipient, the General JSON serialization otherwise

Step 4 (Optional): Re-encrypt/Re-sign with PQC

• Transform from classical to quantum-resistant algorithms
• Endpoints: /api/v3/crypto/reencrypt, /api/v3/crypto/resign (compact or streaming)
• Output: JWE/JWS tokens with PQC algorithms (ML-KEM, ML-DSA, FALCON)
• A result addressed to several keys is accepted too: re-encrypt replaces only the rotated recipient (named in sourceKid) under a fresh content-encryption key, and re-sign verifies every signature and replaces only the rotated one — see Operating on a converted result

See: PKCS#7 Conversion for detailed workflows and examples.

Key distinction: Steps 1-3 are format conversion (PKCS7→JOSE). Step 4 is algorithm conversion (Classical→PQC). These are separate, sequential operations.

Getting Started with Migration

Prerequisites

Before beginning migration, ensure:

• ✅ ANKASecure Core API deployed and accessible
• ✅ Admin API configured for tenant provisioning
• ✅ Authentication (JWT) configured with appropriate scopes
• ✅ License Server validated for usage tracking
• ✅ Trust anchors configured (if using PKIX validation)

Migration Workflow Quick Reference

Example: 30-Minute Migration

For applications already using ANKASecure via SDK/API:

1. Import legacy RSA keys (5 minutes)
2. Analyze certificate status (2 minutes)
3. Generate ML-KEM keys (1 minute)
4. Update key references (configuration change - 2 minutes)
5. Validate operations (10 minutes)
6. Monitor (10 minutes)

Total: 30 minutes, zero code changes

Security Considerations

Migration introduces specific security considerations beyond regular operations:

Legacy Key Security

Imported keys are protected with same rigor as native keys:

• ✅ HSM envelope encryption (all keys wrapped with HSM KEK)
• ✅ Tenant isolation (strict multi-tenant boundaries)
• ✅ Policy enforcement (lifecycle states apply to imported keys)
• ✅ Audit trail (all operations logged with correlation IDs)

Validation Modes

Choose validation mode based on security requirements:

Default: STRICT — the platform setting migration.cert-validation-mode, changed in the Admin Console under Platform Settings → Cryptography & Trust → Migration & Trust and applied without a restart

Trust Anchor Validation

PKIX trust anchor validation (RFC 5280) provides assurance that imported certificates originate from legitimate CAs:

Enabled by default: Validates chains against Mozilla CA bundle (144 public CAs)
Custom CAs: Add corporate root CAs to trust-anchors directory Self-signed certs: Automatically detected, PKIX validation skipped

See: how PKIX validation is configured, and what it rejects, is covered by the import guide delivered with a licensed deployment.

Related Documentation

Core Migration Documentation

• Planning & Assessment - Pre-migration analysis and strategy selection
• Analyze Operations - Compatibility analysis, status determination
• Convert Operations - Data re-encryption, signature conversion
• Utility Operations - Stateless operations, bridge patterns

Supporting Documentation

• API Integration - Cross-API coordination (Admin, Core, License)
• Monitoring & Validation - Health checks, success criteria
• API Reference - Complete endpoint documentation
• Error Reference - one page per failure type URI, with what to change

Not published here

Three parts of this section are procedures rather than contracts, so they travel with a delivery instead of with the public documentation. The step-by-step import guide and the troubleshooting decision matrices are delivered with a licensed deployment — ask whoever operates yours. The worked end-to-end migration walkthroughs (RSA → ML-KEM, RSA → ML-DSA, and a complete 200-application programme) are delivery material ANKATech runs with you — ask your ANKATech contact.

External References

• Crypto-Agility Use Case^* - Business case and ROI analysis
• Key Lifecycle Policy^* - Policy enforcement for imported keys
• Streaming Operations^* - Re-encryption streaming architecture

Version: 3.0.0
Last Updated: 2025-12-24 Status: Production Ready