Per-customer isolation
The platform is multi-tenant with strict logical separation: every read and every write is scoped to your account identifier at both the data layer and the application layer. Your information is not visible or reachable from any other customer's account, and no user-facing global queries exist.
- Continuous verification, not a promise. An automated guard recurrently inspects the production environment for any configuration that could mix information across accounts and reports to the platform's vital signs. Separation is not assumed: it is measured.
- Public surfaces (forms, widgets, webhooks) are minimal and authenticate via tokens or limited-scope identifiers; everything else requires an authenticated session.
- Changes are prepared and tested in a separate working environment before being published to production.
Identity and access control
- Unrecoverable passwords. Stored solely as salted one-way cryptographic hashes (bcrypt). No one, not even OMB's own team, can read or reconstruct them.
- Least-privilege roles. Owner, administrator and user, with per-module permissions: each person sees only what their role requires.
- Hardened sessions. Secure, HttpOnly and SameSite cookies; the remember-me mechanism uses split tokens that rotate on every use and are compared in constant time, so a stolen old cookie does not open the account.
- Two-factor authentication available for accounts that require it, and passkeys being rolled out as the preferred method, as they are phishing-resistant by design.
- Step-up verification per module. Modules you mark as sensitive can require an additional verification upon entry, even with an active session, following online-banking practice.
Encryption
| Layer | Technology | Detail |
|---|---|---|
| In transit | TLS | All communication travels encrypted: portal, API, widgets and integrations. |
| Secrets and credentials | AES-256-GCM | Mail passwords, integration keys and customer-entrusted credentials are stored encrypted with integrity authentication. The master key lives outside the code repository and beyond the web server's reach, with restrictive permissions and lossless rotation. |
| Customer vaults | AES-256-GCM | Third-party portal credentials entrusted by a customer exist only in encrypted form, with no human reading in normal operation and definitive deletion upon request. |
| User passwords | bcrypt | Salted one-way hash. No decryption is possible. |
| Signed documents | SHA-256 + RFC 3161 | Every signed contract is bound to its cryptographic fingerprint with a cryptographic timestamp. |
Perimeter, backups and continuity
- Infrastructure-level firewall and web-server blocking of all sensitive files (configuration, logs, backups, version control): they are not reachable from the internet.
- Session store outside the public tree, with restrictive permissions.
- Daily, verified, encrypted backups. Every database backup is verified before being kept (a backup that fails verification is not kept as good) and encrypted with AES-256 under a dedicated key, distinct from the operational key and held outside both the repository and the backup folder.
- Backups do not violate your privacy. They are used exclusively for restoration, never for consultation. Encrypted-vault information reaches the backup already encrypted with your key: it is unreadable even inside the backup. Rotation is 14 days at most, so a data deletion also disappears from backups within that window.
- Continuous monitoring of the platform's vital signs with anomaly detection.
Traceability and evidentiary documents
- Logging of relevant operations (creations, changes, sends, signatures) with date, time, IP address and user.
- When authorized staff operates in supervision mode, the platform records the real identity of the person acting, not just the account being acted upon.
- Evidentiary documents (contracts and invoices) are generated server-side, bound to their SHA-256 fingerprint, and keep their full event chain. The signed file is demonstrably the document that was shown.