Security

Architecture, cryptography, and honest boundaries — what we protect, what we never hold, and what we cannot recover.

This page is our public security model — architecture, cryptography, infrastructure, compliance posture, and honest limits. It is written for people evaluating LORIIQ for production use, not for marketing reassurance.

LORIIQ is in active development. Do not store credentials you cannot afford to lose until independent cryptographic review is complete. For privacy and legal requests, see our Privacy Policy.

Assurance status

Current state of security controls and review — including what is verified, in progress, open, or an intentional design boundary. We do not use green checkmarks for items that have not been independently validated.

Client-side vault encryption
Vault items are encrypted on your device before sync. Servers store ciphertext blobs only.
Verified in code
Zero-knowledge architecture
We never receive your master password or vault decryption keys. A recovery phrase unlocks ciphertext on your device only — we cannot decrypt for you.
Verified in code
Sync transport encryption (X25519)
Each sync session uses ephemeral key agreement and AES-256-GCM transport wrap in addition to TLS.
Verified in code
Master password policy (signup)
Minimum 12 characters, zxcvbn score 3+, and k-anonymity breach check against known compromised passwords.
Verified in code
Multi-factor authentication
TOTP and WebAuthn are planned. Interim controls: email verification, device sessions, lockout, and rate limits.
Open item
Independent cryptographic audit
Primary pre-GA gate. Design is documented here; implementation has not been reviewed by a third party.
Open item
Internal penetration test
Completed July 2026. Findings tracked internally. Not a substitute for independent third-party testing.
In progress
External penetration test
Independent third-party ethical hacking and penetration testing is engaged. Scope covers production-facing surfaces; formal report and remediation tracking are pending completion.
In progress
SOC 2 Type II
Compliance work in progress with Vanta — not certified.
In progress
HIPAA
Compliance work in progress — not certified. Does not replace a crypto audit.
In progress
Open-source release
Deferred until after independent cryptographic review. Architecture is published; source code is not public today.
By design
Incident response plan
Written operational plan exists. No published customer breach-notification policy or status page yet.
In progress

Architecture: infrastructure quarantine

LORIIQ is built around a simple boundary: plaintext exists only on your device. Everything that crosses our network is ciphertext or operational metadata required to run the service.

We call this infrastructure quarantine — a stricter framing of zero-knowledge design. Our servers orchestrate sync, authentication, and storage. They do not hold keys that decrypt your vault.

If our database and object storage were compromised, an attacker would obtain encrypted blobs and account metadata — not readable passwords, notes, or item names. That protection assumes correct cryptography, strong master passwords, and uncompromised client devices.

Cryptography

All vault cryptography runs in the client before data leaves your device. Parameters below reflect production configuration.

Master password and key derivation

Argon2id slows offline guessing if ciphertext is stolen. It does not make weak master passwords safe — entropy still matters.

At account creation we enforce a minimum length of 12 characters, zxcvbn score of 3 or higher, and a k-anonymity check against known breached passwords (only a partial hash prefix is sent to the breach API; the full password never leaves your device). The server never receives your master password and cannot validate its strength.

Algorithm: Argon2id
Memory: 64 MiB
Time cost: 3
Parallelism: 4
Output: 256-bit master key
Password normalization: NFKC before derivation

Vault items

Algorithm: AES-256-GCM
Fresh random 12-byte IV per encryption
Unique encryption key per vault item
128-bit authentication tag (Web Crypto default)

Account keys and sharing

RSA-4096 key pair generated at registration
Private key encrypted with keys derived from the master password
Sharing uses RSA key wrapping (when sharing ships)

Sync transport (in addition to TLS)

This adds forward secrecy for sync traffic: compromise of one session’s transport keys does not decrypt other sessions. It does not change what is stored at rest — the inner vault blob remains client-encrypted ciphertext.

Ephemeral X25519 key agreement per sync session
HKDF-SHA256 session key derivation
AES-256-GCM wrap of the vault blob for upload and download
Legacy plaintext blob upload paths are rejected by the API

Authentication and sessions

Account login uses email one-time passcodes. OTP codes are hashed at rest before storage; plaintext codes are delivered only to your email.

Sessions use short-lived access tokens and rotating refresh tokens bound to registered devices. You can revoke devices from account settings.

Multi-factor authentication (TOTP and WebAuthn) is not available yet. Do not assume MFA is in place for deployment decisions today.

Email verification before vault access
Per-device sessions with revoke
Login lockout and rate limiting
New-device email notification

Infrastructure and data handling

Production runs on Google Cloud in the United States (API at api.loriiq.com). The API runs on Cloud Run; account data on managed PostgreSQL; vault blobs in encrypted object storage.

Secrets such as database credentials, signing keys, and sync handshake material are stored in Secret Manager — not in source code.

All client traffic uses HTTPS/TLS. Vault sync adds the transport layer described above.

What we store

Account email and verification state
RSA public key and encrypted private key
Key derivation parameters (Argon2id settings)
Authentication verifier (login check — not your master password)
Encrypted vault blob, hash, size, and version
Device name, platform, and session metadata
Audit logs: actions, IP address, user agent, timestamps

What we do not store

Master password
Vault decryption keys
Decrypted item names, URLs, usernames, passwords, or notes
Plaintext vault snapshots

Operational metadata (not zero)

We do not claim zero metadata. Servers necessarily observe blob size, sync frequency, vault version, device identifiers, and audit events. Ciphertext-only applies to vault contents — not to operational telemetry.

Assumed breach: what a server compromise exposes

We design as if our infrastructure will be compromised. The goal: stolen server data should not yield readable secrets without each user’s master password.

If an attacker obtained our database and encrypted object storage, they could access account emails, encrypted vault blobs, KDF parameters, public keys, encrypted private keys, authentication verifier hashes, device records, session metadata, and audit logs.

They would not obtain master passwords or decrypted vault contents — we do not possess them.

Offline attacks against stolen ciphertext remain possible. Effectiveness depends on master password strength and Argon2id cost — not on server-side controls after exfiltration.

Under a lawful request we can disclose data we hold (account email, ciphertext blob, metadata, audit logs). We cannot produce decrypted vault contents or master passwords. See our Privacy Policy for legal requests.

Compliance and independent review

LORIIQ is in active development. We will not claim certifications, audit outcomes, or security guarantees we have not earned.

SOC 2 Type II and HIPAA compliance work with Vanta is paid and in progress — not certified. Vanta covers compliance process and control evidence; it does not substitute for an independent review of our cryptography.

No independent cryptographic audit has been completed. That review is the primary security gate before general availability.

Internal penetration testing was completed in July 2026. Findings are tracked and remediated internally.

We have engaged an independent security firm for ethical hacking and third-party penetration testing. The engagement is underway; a formal report and remediation cycle are pending. This does not replace an independent cryptographic review.

A written incident response plan exists for security events. We have not published a customer-facing breach notification policy or status page.

Open-source release of core cryptography is deliberately deferred until after the independent crypto audit. This page documents the design; it is not a substitute for source review.

Clients and product scope

Web app, browser extension, CLI, and desktop client are in active development with client-side encryption and sync transport wired. Native mobile is not built.

Enterprise capabilities on the roadmap — SSO, SCIM, shared vaults, self-hosting — are not available for deployment evaluation against current builds.

Cloud sync is automatic when the API is configured. There is no user-facing toggle to disable cloud sync today. Local-only operation is possible only in specific deployment configurations, not as a standard product control.

Master password and recovery

We never receive your master password or vault decryption keys. Support cannot read your vault or regenerate a lost recovery phrase.

New computer or cleared browser: sign in, download the encrypted vault, and unlock with the same master password.

If you set up a 12-word recovery phrase at vault creation, you can restore vault contents client-side and choose a new master password — including after the primary cloud vault was deleted — as long as the recovery kit remains. Lost phrase + no local vault + wiped primary = permanent loss.

Account login reset rotates the sign-in verifier only. It does not decrypt or re-wrap your vault. Use /recover with your phrase to change the master password while keeping vault data.

Passkeys and emergency access to another person are planned — not shipped.

Known limitations

No security architecture eliminates every threat. These boundaries are stated explicitly so you can evaluate residual risk — not discover them after deployment.

Threat	Scope	Detail
Lost master password without recovery phrase	Not recoverable by LORIIQ	Use the 12-word recovery phrase if you saved one; otherwise vault contents cannot be restored by support.
Weak master password after blob theft	Partially mitigated	Argon2id slows guessing; weak passwords can still fall to offline attack.
Compromised device (malware, keylogger)	Out of scope	Secrets in memory while vault is unlocked; auto-lock reduces window only.
Clipboard hijacking	Out of scope	30-second best-effort clear on copy; OS clipboard risks remain.
Phishing / tricked autofill	Partially mitigated	Autofill requires user click and domain match; social engineering remains.
Server infrastructure breach	Mitigated (design)	Ciphertext and metadata only — assumes crypto correct and passwords strong.
Server traffic metadata	Observed	Blob size, sync timing, device signals, audit events.
Insider with database access	Mitigated for plaintext	Insider gets ciphertext and metadata — not decrypted vault contents.
Legal order for decrypted data	Cannot comply	We do not hold master passwords or decrypted vaults.
No MFA today	Open	Email OTP and device sessions only until TOTP/WebAuthn ship.
Unaudited cryptography	Open	Implementation bugs may exist until independent review completes.
Company shutdown	Out of scope	Users need a local copy; no guaranteed export SLA in product today.

Report a security issue

If you believe you have found a vulnerability in LORIIQ, email security@vitatechgroup.com with a description and steps to reproduce.

Please do not disclose publicly until we have had reasonable time to investigate. We do not operate a paid bug bounty program today. We acknowledge good-faith reports and will work with you on coordinated disclosure.