Zero-knowledge credential vaulting: how we protect applicant passports

Before we talk about encryption, we have to be honest about what's being protected. Visa portal credentials are not social-media passwords — they unlock an identity that contains passport number, date of birth, travel history, sometimes biometrics, sometimes tax records, and a full picture of an applicant's movements for the next ten years. If an attacker compromises a credential store for a visa automation platform, the downstream risk is identity theft at passport-grade severity, not just a rebooked flight.

The specific threats we designed against:

• Database exfiltration. A dump of our Postgres must not expose any applicant credential in plaintext, even if the attacker has the database-level encryption key.
• Insider read. No Opaige engineer, operator, or support agent should be able to see an applicant's portal password, at any point, through any interface.
• Worker compromise. If one Playwright worker is compromised, that incident must not grant access to credentials belonging to applicants it never processed.
• Audit traceability. Every decryption event — even authorised — must produce a signed log line that a compliance team can read in sequence.

A database dump contains none of those fields in usable form. To decrypt even one credential, an attacker would need access to the KMS master key, not just the database. Because each applicant has a unique data key, compromising one applicant's session cannot cascade to the rest.

Plaintext credentials exist exactly three places, for exactly as long as they need to:

• In the applicant's browser when they first submit them — HTTPS in transit, TLS 1.3.
• In memory of a single Playwright worker process when it is logging into the portal on behalf of that applicant. The plaintext is zeroed the moment login completes.
• In the actual portal's credential form where they are typed. Not our surface.

We cannot look up a customer's VFS password for them — and that is deliberate.

Every decryption event writes an append-only audit row with the data key ID, the reason (usually a worker run ID), a timestamp, and the IP and process that performed the decrypt. These rows are signed with a separate HMAC so a database-level attacker cannot edit history without leaving a trace.

For B2B customers in regulated industries — EORs, relocation platforms, immigration law firms — the audit trail ships as a queryable report via a dedicated endpoint. Your compliance team can diff yesterday's decrypts against their expected work and flag anomalies without waiting on an Opaige human to pull logs.

We are happy to walk an enterprise security team through the implementation, share the specific KMS provider, and provide evidence bundles for an audit. Email security@opaige.com.