Security architecture. As built in Switzerland North.
Technical description of how the hosted platform protects data — for security and infrastructure reviewers. A shorter overview lives on the Security & deploymentarrow_right page.
Version September 2026 · Effective · Classification: External
1. Overview
iown is designed for sensitive financial, legal and ownership data. Security, privacy and Swiss data residency are foundational to how the hosted platform is built and operated.
Protection is layered: client-side encryption for selected vault fields and documents; TLS in transit; and infrastructure encryption at rest under iown-managed keys, with double encryption on disks and encryption at host on compute. These controls strengthen key custody and reduce Microsoft operator access to data at rest. They do not mean that Microsoft cannot access data in all circumstances, and they are not the same as confidential computing (in-use isolation).
2. Architecture summary
Frontend. React-based secure client with client-side encryption for selected sensitive fields and documents.
Backend. Stateless API services; sensitive vault payloads remain encrypted with client-controlled keys where that model applies.
Infrastructure. Microsoft Azure Switzerland North — AKS, Azure Database for PostgreSQL (Flexible Server), Azure Blob Storage, Azure Key Vault Premium (HSM), Disk Encryption Sets, encryption at host.
Data model. Graph-based ownership, relationships and financial entities.
AI layer. Domain-specific tax/legal models trained on public regulations and domain documentation — not on client vault data. Optional external providers per configuration.
3. Data protection principles
3.1 Encryption layers
In transit. TLS 1.2+ for client–service communications. In-product audio/video uses a separate end-to-end mechanism.
Client-side. Selected sensitive fields and documents are encrypted in the browser. Vault unlock keys are user-controlled; iown cannot recover a lost vault key.
At rest (infrastructure). Disks, storage accounts and PostgreSQL use AES-256-class platform cryptography, keyed by iown-managed keys in Azure Key Vault Premium (HSM-backed RSA-4096). Disks use Azure double encryption (platform key + iown key via Disk Encryption Set).
Encryption at host. Eligible AKS node pools and VMs enable Azure EncryptionAtHost so the host OS and temp disks participate in the encryption boundary for data at rest on the host.
Key custody. Infrastructure keys are iown-managed (held in iown’s Swiss Key Vault). This is not end-customer BYOK. Firm-managed BYOK is an optional extra.
Confidential computing. Azure Confidential VMs provide hardware TEE isolation for data in use. Confidential capacity is available in the Switzerland North infrastructure and is a separate control from the at-rest protections above.
3.2 Data minimization & pseudonymization
Sensitive data is not processed in raw form unless required for the requested operation. Where AI processing needs structure context, internal systems may use pseudonymized identifiers while preserving relationships.
3.3 Secure document storage
Documents intended for vault protection are encrypted before storage with the client/user key model on the frontend where applicable. They are stored in Azure Blob Storage in Switzerland North under storage CMK (iown-managed storage key encryption key), with authorization policies and vault roles.
4. Infrastructure encryption (Switzerland North)
The hosted platform encryption posture below is live as of . Names are operational identifiers for reviewers.
Key Vault Premium
kv-iown-cmk-chn in Switzerland North — purge protection enabled, HSM-backed.
Frontend and backend storage accounts encrypt with iown-storage-kek.
PostgreSQL CMK
Flexible Servers run as *-postgresql-cmk with iown-pg-kek.
AKS (iown-cluster)
Node pools use encryption-at-host with DES-attached OS disks.
Parse / Qdrant host
iown-parse-vm hardened with encryption-at-host and DES/disk CMK.
EncryptionAtHost
Subscription feature Registered; applied on eligible AKS pools and VMs.
Confidential compute
Confidential VM capacity (DC*/EC* families) available for TEE-isolated workloads.
Threat model. CMK, encryption-at-host and double encryption strengthen at-rest protection and iown key control, and reduce Microsoft operator access to data at rest. In-use isolation is handled separately by confidential compute, and neither layer supports a claim that “Microsoft cannot access data.”
5. AI & LLM data safety
Private, ring-fenced model options for tax/legal assistance.
Use of public models (for example OpenAI or Claude) is optional and configuration-dependent.
Client identifying data is anonymized or pseudonymized before LLM processing where that pipeline applies.
Models are not trained on client vault data.
Training and grounding material for domain models draws on public regulations, tax law and domain documentation.
6. Data residency & deployment
Primary hosting region is Microsoft Azure Switzerland North. Core components are AKS, Azure Database for PostgreSQL Flexible Server, Azure Blob Storage, Azure Key Vault Premium and Disk Encryption Sets. Clients needing full infrastructure control can discuss on-premises or client-infrastructure deployment.
7. Access control & authentication
Multi-factor authentication (MFA) for users.
Role-based access control (RBAC) and vault roles with least-privilege intent.
Invitation approval, session controls and selected snapshot sharing for sensitive work.
8. Auditability & transparency
Significant system activities leave an audit trail. Event logging covers data access, modifications and authentication events where instrumented. Logs are retained under controlled storage policies.
9. Data isolation & backend design
Backend services are designed to be stateless with respect to long-lived sensitive client memory. Application logic, data storage and encryption layers stay strictly separated. Client-side vault encryption means the platform does not hold recoverable plaintext for those fields without the user’s key.
10. Third-party data policy
No third-party sharing of client vault data without client approval or a contractual basis.
No external analytics tools with access to client vault contents.
Processing occurs within controlled infrastructure and approved provider configurations.
11. Compliance & security posture
The platform aligns with established practices from GDPR principles, financial-data handling norms and Azure cloud security benchmarks. Specific certifications or attestations are stated only when independently obtained.
12. Key security guarantees
Live posture
Client-side encryption of selected sensitive fields and documents.
TLS 1.2+ encryption in transit.
Swiss data residency on Azure Switzerland North.
iown-managed infrastructure keys in Azure Key Vault Premium (HSM-backed RSA-4096).
Double encryption at rest on disks (platform + iown key).
Storage and PostgreSQL encryption under iown-managed keys.
Encryption at host on AKS node pools and hardened VMs.
Confidential VM capacity for TEE-isolated workloads (data in use).
Encrypted document storage with authorization controls.
Pseudonymized internal references for AI where applicable.
iown combines client-side vault encryption, Swiss residency, iown-managed HSM keys, double encryption at rest, encryption at host and confidential compute for in-use isolation. Together with operational controls and least-privilege access, this design keeps sensitive ownership and tax work confidential and under clear key custody.
