Security Architecture
Security is not a feature we add — it is the foundation every layer of SecureOTP is built on. This document describes how we protect your data, your API keys, and your end users' OTP codes from ingestion to delivery.
Three security pillars
Every design decision is evaluated against these three properties.
Encryption at Every Layer
TLS 1.3 in transit. AES-256 at rest. API keys stored as salted hashes — never retrievable in plaintext after issuance.
Zero-Trust Access
All internal service-to-service calls require mutual TLS and short-lived JWT tokens. No implicit trust between components.
Defence in Depth
Multiple independent control layers — WAF, rate limiting, anomaly detection, and human review — so no single failure creates exposure.
Defence-in-depth layers
A request travels through six independent security layers before an OTP is dispatched to a carrier.
- check_circleAnycast routing absorbs volumetric attacks at the network edge before traffic reaches application servers.
- check_circleLayer 7 Web Application Firewall (WAF) blocks OWASP Top 10 attack patterns, SQL injection, and bot traffic.
- check_circleAutomatic rate-limiting per API key, per IP, and per destination number to prevent abuse.
- check_circleAll API requests require a valid HMAC-signed API key. Keys are scoped to specific operations (send-only, read analytics, admin).
- check_circleRequests exceeding plan limits are rejected with a 429 response before reaching internal services.
- check_circleMutual TLS enforced between the gateway and all downstream microservices.
- check_circleOTP content is never logged. Only metadata (timestamp, destination country code, carrier, status) is persisted for billing and debugging.
- check_circleIntelligent carrier selection routes each message via the path with the highest recent delivery rate for the destination.
- check_circleAutomatic failover to a secondary carrier within 30 seconds if the primary path degrades.
- check_circleAll databases are encrypted at rest with AES-256, with keys managed by a dedicated Hardware Security Module (HSM).
- check_circlePersonally identifiable data (email, company name, billing details) is stored separately from telemetry data under stricter access controls.
- check_circlePoint-in-time recovery with 30-day retention. Backups are encrypted and replicated across availability zones.
- check_circleWorkloads run in isolated Kubernetes namespaces with network policies that enforce least-privilege inter-service communication.
- check_circleProduction and staging environments are in separate accounts with no shared credentials.
- check_circleImmutable infrastructure — servers are never patched in place; deployments replace running images atomically.
- check_circleEngineers access production systems only via a privileged access workstation with hardware MFA, through a bastion with full session recording.
- check_circleLeast-privilege IAM roles: each team member has access only to the resources required for their role, reviewed quarterly.
- check_circleAll privileged actions are logged immutably in a separate audit trail inaccessible to standard engineers.
What happens to an OTP code
Transparent trace of an OTP request from your server to your user's phone.
API request received
Your server submits a POST request over TLS 1.3. The API gateway validates the HMAC-signed key and scopes within milliseconds.
OTP generated
A cryptographically random code is generated using a CSPRNG seeded from the host OS entropy pool. The code is held in memory only — never written to disk or logs.
Carrier selected
The routing engine scores available carriers for the destination country based on real-time delivery rates and latency. The highest-scoring carrier is selected.
Message dispatched
The OTP is transmitted to the carrier over an encrypted SMPP or WhatsApp Business API connection. After dispatch, the plaintext code is discarded from memory.
Status recorded
Only metadata is persisted: timestamp, destination country code (not the number), carrier ID, and delivery status. No PII is stored at this stage.
Delivery confirmed
Carrier delivery receipts update the status record. Your webhook (if configured) receives a signed callback. The OTP code has never existed in our storage.
Ongoing security operations
Architecture alone is not enough — we maintain a continuous security programme.
Vulnerability Disclosure
We operate a responsible disclosure programme. Security researchers can submit findings to [email protected]. We acknowledge within 24 hours and aim to remediate critical issues within 72 hours.
Penetration Testing
Independent third-party penetration tests are conducted annually against the API, console, and internal network perimeter. Findings are triaged and remediated in order of severity.
SOC 2 Type II (In Progress)
We are currently completing our SOC 2 Type II audit covering Security, Availability, and Confidentiality trust service criteria. Reports will be available to enterprise customers under NDA upon completion.
Dependency Management
All third-party dependencies are pinned and automatically scanned for CVEs. Critical vulnerabilities trigger a same-day hotfix process. SBOMs are maintained for all production services.
Security Training
All employees complete security awareness training quarterly. Engineering staff complete role-specific training on secure coding, threat modelling, and incident response annually.
Incident Response Plan
A tested incident response plan defines roles, escalation paths, and communication procedures. Tabletop exercises are conducted bi-annually to validate readiness.
Found a vulnerability?
We welcome responsible disclosure from the security community. Report findings to [email protected] — we acknowledge within 24 hours and remediate critical issues within 72 hours.