RFC 6749 — OAuth 2.0
Authorization code and client credentials grants. No implicit grant. Refresh-token rotation with family tracking.
Security
Security review starts here.
1. Data residency
All customer data is stored and processed inside the European Union. Production infrastructure runs on Hetzner, in German data centres (Falkenstein and Nuremberg). No US cloud providers sit in the hot path for authentication, token issuance, or credential verification.
- Kubernetes cluster on Hetzner Cloud, German regions only
- PostgreSQL and Redis co-located with the application
- Backup targets are EU-only S3-compatible storage
- Dutch incorporation — no US corporate reach into infrastructure
2. Key management
Signing keys for JWT access tokens and OIDC ID tokens live in HashiCorp Vault Transit. Keys never leave Vault — the application calls Vault to sign; the raw key material never touches the JVM process. Credentials stored in Cloud Wallet are encrypted at rest with AES-256-GCM; per-user wrapped keys via Vault Transit are on the roadmap.
- Vault Transit signs; raw private keys never leave Vault
- AES-256-GCM for credentials at rest in Cloud Wallet
- Vault deployed as a separate Helm release with its own backup schedule
- Daily encrypted Vault snapshots, EU-only storage
3. Access control and internal security
Production access is limited to the founders and named on-duty engineers. All admin access is authenticated via MFA-backed SSO. Privileged access is reviewed monthly. There is no shared root account.
- MFA-backed SSO for every admin tool
- Kubernetes RBAC bindings per operator
- Monthly privileged-access review; revocations audited
- No shared root credentials; no production break-glass without a two-person audit trail
4. Incident response
We maintain an on-call rotation with a ≤24h customer-notification commitment for P1 incidents (confirmed breach of confidentiality, integrity, or availability affecting customer data). The incident-response runbook is maintained in the team password manager and reviewed quarterly.
- On-call rotation across the founding team
- ≤24h notification SLA for confirmed P1 affecting customer data
- Runbook with escalation contacts and notification templates
- Post-incident writeup template; findings shared with affected customers
5. Compliance roadmap
We do not currently hold SOC 2 Type I or Type II certification. What exists today: GDPR-compliant data handling, NIS2-aligned controls (documented and self-assessed), and eIDAS-aligned technical architecture for the verifier and issuer products. SOC 2 is on the 2026–2027 roadmap alongside our first external pentest. We would rather tell you the truth now than collect a badge later.
- GDPR — Article 30 processing register; DPIA for identity-service user data
- NIS2 — technical and organisational controls self-assessed and mapped
- eIDAS 2.0 — technical architecture aligned with ARF 1.4+
- SOC 2 Type I planned for 2027; Type II to follow
6. Penetration testing
We have not yet engaged an external pentesting firm. Internal red team exercises are run per-release on critical flows — OAuth authorization, token exchange, credential presentation. A first external pentest is planned alongside the SOC 2 work. The broker's red-team demo is a live exercise of protocol-level defences (replay, tampered claim, expired credential, wrong issuer).
- Internal red team exercises per-release on auth / credential flows
- Broker red-team demo: live protocol-level attack simulation
- First external pentest: planned 2026–2027
- Public summary of pentest findings once complete
7. DPA availability
A Data Processing Agreement is available on request before you sign a commercial contract. The standard template is SCCs-based EU model clauses with a Thoryn-specific processing schedule. Customer-modified DPAs are accepted subject to legal review.
8. Standards we implement
Implementation claims, not certifications. We build against the specs; we test against them; we publish our conformance. Where we differ from a reference implementation, we say so.
RFC 7636 — PKCE
Required on every public client. S256 challenge method. No plain challenges accepted.
RFC 9126 — PAR
Pushed Authorization Requests required for broker flows. Request objects never travel over the front channel.
SD-JWT VC
Selective-disclosure verifiable credentials. Accepted by the broker; issued by Cloud Wallet. Undisclosed claims are cryptographically unreachable.
OpenID4VP
Verifiable Presentation protocol. The broker's verifier path is tested against the NL reference wallet and the EU reference wallet.
eIDAS 2.0 ARF
Architecture and Reference Framework alignment for the EUDIW relying-party flow. We track ARF revisions and ship updates without requiring integration changes.
9. Regulatory mappings
Match your regulation to the Thoryn capability that addresses it. Every row links to a live verification demo.
| Regulation | Binding date | Thoryn capability | Demo |
|---|---|---|---|
| NIS2 Art. 21(2)(d) supply-chain measures | In force | Per-event tenant-scoped audit chain. Queryable via API within 72 hours, without log aggregation. | See it |
| BRZO 2015 / Seveso III | In force | Contractor identity plus 7-year audit-replay through historical JWKS. | See it |
| ISPS / AVSEC (EU Reg. 300/2008) | In force | Multi-employer federation across 200–2000 contractors per day. | See it |
| Wbn (Kernenergiewet) | In force | 10-year cryptographic replay through historical JWKS. Vault Transit signing. | See it |
| CRA | Dec 2027 | Pre-binding evidence-chain support for software supplier credentials. | See it |
| IAEA Safeguards | In force | Audit replay covering inspection cycles. | See it |
| SOC 2 Type II / ISO 27001 supply-chain | Tenant-driven | Per-tenant query API for "who entered rack X at time Y". | See it |
Every row above is satisfied by the same audit chain. One verification path, written once, replayable seven years out.
10. Subprocessors
Every third party that processes customer or site data is disclosed in the subprocessor list — who they are, what they do, and what data they see.
Have more questions?
30 minutes with a founder or engineer — we'll walk through your security requirements and answer anything we didn't cover above.