Skip to content

IDV Platform Security Guide

Security requirements for deploying and operating the Regula Identity Verification (IDV) Platform.

Overview

The IDV Platform protects personal data in transit and at rest.

The Platform uses application-level encryption for selected data. The IDV SDK adds another protection layer by using an Elliptic Curve Diffie-Hellman (ECDH) handshake to establish session keys for secure data transfer.

If you deploy IDV on dedicated hardware, you must also protect the underlying infrastructure. This guide describes the minimum security requirements.

Architecture and Communication (Security View)

System boundaries

Backend handles orchestration, workflows, audit, indexing, and calls to document and face processing services.

Client tier includes web, mobile, and server integrations that use the authenticated and authorized IDV API (authenticated and authorized at the API layer).

Persisted data contains:

  • MongoDB stores structured data.
  • Object storage stores unstructured binary data such as images and documents.
  • Vector database supports biometric search.

Message broker is RabbitMQ, which handles system messaging.

General Principles

Implement encryption for both data at rest and data in transit across all system components where it possible.

Internal communication

  • Restrict databases, search, and broker to approved subnets and identities.
  • DocReader and FaceAPI (or equivalent URLs in platform configuration) should use private networks and HTTPS whenever traffic leaves a tightly controlled path.

External communication

  • Terminate TLS at a load balancer in front of the API.
  • Public integration surfaces should be HTTPS only.

Data Persistence

  • Ensure all your storage systems are encrypted at rest.

Data at Rest

Use defense in depth: combine disk or service encryption with any application-level encryption the Platform provides.

MongoDB

Deployment Practice
Self-managed / on-premises
  • Enable MongoDB encryption at rest where the edition supports it.
  • Encrypt underlying volumes (OS or storage vendor).
  • Restrict filesystem access.
  • Encrypt backups.
See MongoDB encryption at rest.
MongoDB Atlas
  • Use Atlas encryption at rest, which is enabled by default on clusters.
  • Use cloud KMS integration if your policy requires it.
See Atlas encryption.

Application layer

The Platform encrypts selected database fields by using a configured symmetric key (fernetKey) and the AES-128 algorithm in CBC mode. This protects sensitive data at the application layer, but it does not replace disk-level encryption.

Generate encryption keys with a cryptographically secure random number generator. Store them in a secrets manager, separate from the database. This separation helps protect data if database backups are exposed.

Personal Data Transfer (SDK Layer)

The Document Reader SDK and Face SDK capture and transmit document and biometric data. They use Elliptic Curve Diffie-Hellman (ECDH) to create unique session keys for each transmission. This adds end-to-end encryption and helps protect sensitive data in transit from interception or unauthorized decryption.

Context Practice
Self-managed OpenSearch
  • Encrypt data volumes.
  • Enable security plugin features appropriate to the edition (TLS, access control).
See OpenSearch security.
AWS OpenSearch Service
  • Enable managed encryption at rest.
  • Enable TLS for client and cluster traffic.
See AWS OpenSearch encryption at rest.
Atlas (vector workloads)
  • Apply the same encryption and network rules as for the primary Atlas cluster.

Storage

Backend Practice
Amazon S3
  • Use server-side encryption based on your policy: SSE-S3, SSE-KMS, or SSE-C.
See S3 server-side encryption.
Azure Blob
  • Use Microsoft-managed keys or customer-managed keys (Storage Service Encryption).
See Azure storage encryption.
Google Cloud Storage
  • Use default encryption at rest.
  • Use CMEK if your policy requires it.
See GCS encryption and customer-managed keys.
Local filesystem
  • Local storage has no built-in cloud encryption. Use full-disk encryption, strict OS permissions, and encrypted backups.
  • Avoid local filesystem storage for sensitive production data unless you have explicit compensating controls.

Store keys, connection strings, and service account credentials in a secrets manager. Use least-privilege policies for buckets and containers. Allow public access only with formal approval.

Message broker (RabbitMQ)

Context Practice
On-premises
  • Encrypt disks that store durable queues.
  • Use TLS for client connections and federation.
  • Use strong authentication (unique passwords, limited vhosts).
Persistence: RabbitMQ persistence.
Managed messaging
  • Enable provider-managed encryption at rest.
  • Use TLS endpoints only.
  • Disable anonymous access.

Data in Transit

To protect data in transit, follow these requirements:

  • Sensitive data in motion MUST use TLS 1.2 or later.
  • Do not use SSLv3, TLS 1.0, or TLS 1.1.

Internet-facing and client paths

Topic Practice
TLS settings
  • Terminate TLS on a hardened edge.
  • Use strong cipher suites.
  • Disable weak algorithms.
  • Prefer TLS 1.2 or later.
  • Adopt TLS 1.3 where supported.
Certificates
  • Use a public CA or enterprise PKI.
  • Make sure clients trust the certificate chain.
  • Automate certificate renewal.
  • Monitor certificate expiry.
  • Enforce hostname verification.
HTTP
  • Use HSTS where you control browser clients.
  • Redirect HTTP to HTTPS only after testing the rollout.
API
  • Route all client access through the authenticated IDV API.
  • Do not allow anonymous access to processing backends.

Vendor TLS references (data plane)

Component Documentation
RabbitMQ TLS / SSL
MongoDB Configure TLS/SSL
OpenSearch TLS configuration

Component Security Summary

Component Role Data at rest Data in transit
API Main entry point for incoming requests Not applicable TLS 1.2+ terminated on the Load Balancer
Workflow Executes the core business logic of the Platform Not applicable Handled via Message Broker communication
Scheduler Runs background tasks such as cleanup jobs Not applicable Handled via Message Broker communication
Audit Writes and stores audit logs for traceability and compliance Not applicable Handled via Message Broker communication
Indexer Builds search indexes in the background Not applicable Handled via Message Broker communication
MongoDB Primary operational database Encryption at rest + volume encryption, optional field encryption via platform key TLS; validated connection parameters
RabbitMQ Event bus between UI-facing and backend parts Encrypted disk for durable queues; retention limits TLS / amqps; unique broker credentials
Storage (S3 / Azure Blob / GCS) Unstrucured binary data SSE / KMS (S3), Microsoft or customer keys (Azure), GCS defaults or CMEK HTTPS only; enable secure client flags in configuration

Operational Checklist

  • TLS 1.2+ end-to-end on untrusted segments.
  • mTLS is enabled for data plane where feasible.
  • Encryption at rest is enabled for DB, object storage, search, and broker (or managed-service equivalent).
  • Secrets such as storage keys, broker URLs, OAuth/SAML material, fernetKey, third-party API keys are stored in a secrets manager.
  • Secrets are rotated on a schedule and after incidents where possible.
  • Network segmentation and least-privilege IAM are in place.
  • The IDV API is the only controlled client entry point.
  • Logging and monitoring are enabled.
  • Access to logs that may contain PII or session identifiers is restricted.