# Mobile-ID QuantumSafe Deployment Models

## 1. On-premises
For regulated organizations requiring local control of applications, data, HSM/QSCD and evidence.

**Typical components:** Crypto Discovery, Control Plane, CA/RA/VA/TSA, HSM/KMS, providers, verification and evidence repository.  
**Evidence:** trust-boundary diagram, data-flow record, key ceremony, HA/DR test and operating runbook.

## 2. Private cloud
For Kubernetes/OpenShift or dedicated cloud environments with tenant and data-residency controls.

**Typical components:** containerized services, dedicated database and object storage, HSM or approved cloud-HSM connection, observability and CI/CD.  
**Evidence:** tenancy model, secrets boundary, network policy, backup/recovery and platform-version matrix.

## 3. Integrated appliance
For pre-integrated controlled deployments combining software, HSM/QSCD/SAM and hardened operations.

**Typical components:** managed configuration, health monitoring, secure update, local audit and restricted administration.  
**Evidence:** bill of materials, hardened baseline, acceptance test, update policy and lifecycle plan.

## 4. Managed service
For customers delegating agreed operational activities to Mobile-ID while retaining defined governance and approval rights.

**Typical components:** managed monitoring, standards watch, lifecycle review, evidence refresh, incident and change workflow.  
**Evidence:** SLA, RACI, data-processing boundary, access control, audit, retention and exit plan.

## 5. Hybrid deployment
For phased migration where classical infrastructure remains active while hybrid/PQC pilots and new trust services are introduced.

**Typical components:** dual profiles, compatibility gateway or provider, staged relying parties, fallback controls and migration waves.  
**Evidence:** transition architecture, supported matrix, downgrade policy, cutover/rollback and decommission criteria.

## Mandatory design questions
1. Where are private keys generated, stored and used?
2. Which data leaves the customer boundary?
3. Which product, firmware, provider and algorithm profile is approved?
4. How are relying parties and legacy verifiers handled?
5. How are evidence, logs and exceptions preserved?
6. What triggers rollback and who approves it?