Jmoor holds payroll, tax, and banking data and moves real money — so security is built into every layer of the platform, from cryptography and tenant isolation to payments and incident response. Here’s exactly how.
Security at a glance
TLS in transit, AES-256-GCM at rest, and purpose-isolated keys derived via HKDF.
Postgres row-level security (FORCE RLS) keeps every tenant’s data strictly separate.
Argon2id credentials, opt-in MFA, RBAC, and host-bound admin sessions.
Immutable audit trails and always-on vulnerability monitoring.
Jmoor moves money and holds some of the most sensitive information a business owns — payroll, tax identifiers, bank details, and financial records. We treat security not as a feature bolted on at the end, but as a property designed into every layer of the platform: cryptography, identity, data isolation, network, application logic, payments, and operations.
Our approach follows defence-in-depth and least-privilege: no single control is trusted on its own, and every component is given only the access it strictly needs. Sensitive actions are gated by multiple independent layers, so the failure of any one control does not expose data or funds.
Security at Jmoor is continuous, not a point-in-time exercise. Threats, dependencies, and configurations are monitored on an ongoing basis, and controls are reviewed and hardened as the platform and threat landscape evolve.
Data is encrypted both in transit and at rest, and the keys that protect it are isolated by purpose so that a single key never protects everything.
All connections to Jmoor are served over HTTPS using modern TLS. HTTP Strict Transport Security (HSTS) is enforced with a long max-age and preload, so browsers refuse to connect over plaintext. TLS is terminated at a hardened reverse proxy, and application services are not directly reachable from the public internet.
Sensitive personal and financial fields (such as government identifiers and bank account details) are encrypted at the application layer using AES-256-GCM authenticated encryption before they are written to the database — so the data is protected even at the storage layer.
Jmoor derives purpose-specific encryption keys from a single high-entropy root key using HKDF (HMAC-based key derivation, SHA-256). Distinct keys are derived for distinct purposes — field-level PII, multi-factor secrets, partner credentials, and mutual-TLS material — so compromise of one context does not compromise another. Root and derived keys are held in the runtime environment and secret store only; they are never written to logs, error reports, or source control.
Key controls
Access to Jmoor is protected by strong credential handling, optional multi-factor authentication, and role-based authorization at every layer.
Passwords are never stored in plaintext or reversible form. They are hashed with Argon2id — a memory-hard algorithm resistant to GPU and ASIC cracking — using strong work-factor parameters. Repeated failed sign-in attempts trigger lockout, and reset flows are time-limited and single-use.
Two-factor authentication (TOTP) is available to every account and is enabled by the user from their own security settings — you scan a QR code with an authenticator app and confirm a code. By design, 2FA is opt-in and never forced at first login, and once enabled it is required on every subsequent sign-in.
Every user acts under a defined role. Within a workspace, roles range from Owner and Admin through Operator, Viewer, and self-service Employee, plus a Practitioner role for accounting firms acting on client files under an explicit grant. Platform staff operate under a separate set of least-privilege roles, and permissions are enforced server-side on every request — never trusted from the client.
Sessions are protected with secure, HTTP-only cookies, CSRF double-submit tokens on state-changing requests, idle and absolute timeouts, and server-side session validation. Sessions can be revoked centrally.
The platform administration console is held to a materially higher standard than ordinary access, because it is the most valuable target on the platform.
How the admin console is isolated
Obscurity is used as one layer among many — never the only one. Even with the exact host, access still requires valid credentials, passes role-based authorization, and is bound to the admin host at the API layer.
Jmoor is multi-tenant, and keeping each customer’s data strictly separate is a foundational guarantee — not a convention.
Isolation is enforced in the database itself using PostgreSQL Row-Level Security (RLS) with FORCE RLS enabled, so policies apply even to privileged database roles. Each request establishes an authenticated tenant context, and every query is transparently constrained to that tenant’s rows. A request that presents a session for one tenant cannot read or write another tenant’s data — cross-tenant access is rejected rather than filtered by application code alone.
Application services run behind a hardened reverse proxy that terminates TLS and applies a strict security posture before any request reaches application code.
Edge & network controls
Secrets required by services are provisioned from encrypted secret storage at deploy time and are never committed to source control.
Security controls are built into the application logic that handles money and data movement.
Controls
Jmoor orchestrates payments across multiple certified payment processors. Card and sensitive payment data is handled so that Jmoor’s own exposure to raw cardholder data is minimized.
Card details are captured and tokenized by PCI-DSS-certified processors; Jmoor works with tokens and references rather than storing raw card numbers. This design keeps Jmoor aligned with a PCI DSS SAQ-A posture for card acceptance, while payouts, rails, and reconciliation run through the orchestration layer with idempotency and signature verification throughout.
PCI DSS Level 1 certification for the broader platform is in progress. Today, card acceptance is designed around certified processors and tokenization so that raw card data is not stored by Jmoor.
Sensitive actions across the platform are recorded to an append-only, tamper-evident audit trail, giving customers and operators a reliable record of who did what and when. Full audit exports are available to authorized administrators.
The platform is monitored on a continuous basis. Dependencies and configurations are tracked against public vulnerability intelligence (such as NVD, OSV, and CISA KEV), and prioritized using exploit-likelihood signals so that the highest-risk issues are addressed first.
Jmoor maintains an incident-response process oriented around prevention, rapid containment, and recovery. In the event of a security incident, our priorities are to contain the issue, protect customer data and funds, investigate root cause, and remediate.
Where a breach creates a real risk of significant harm, Jmoor is committed to notifying affected customers and the appropriate authorities in line with applicable law, including breach-reporting obligations under Canadian privacy law (PIPEDA). Customers are kept informed of material incidents that affect their data.
If you believe your account has been compromised, contact us immediately at security@jmoor.com so we can help you secure it.
Customer data is backed up on a regular basis with point-in-time recovery, and disaster-recovery material is protected with encryption and held to support recovery of critical systems. Money movements post to a reconciled double-entry ledger, so financial state can be verified and reconstructed.
We welcome reports from security researchers. If you discover a potential vulnerability, please report it privately to security@jmoor.com with enough detail for us to reproduce it. We ask that you give us a reasonable opportunity to remediate before any public disclosure, and that testing avoids privacy violations, data destruction, and service disruption.
Report a vulnerabilityJmoor Security Team
