SaaS security for Australian businesses.
Built like a bank.

Most SaaS platforms treat security as a checkbox. We treat it as an engineering constraint. We publish our full security architecture on this page because we have nothing to hide — knowing how we protect your data doesn't help anyone bypass it.

Security you'd expect from your bank

Argon2id Password Hashing

Passwords are hashed with Argon2id — a memory-hard algorithm designed to resist GPU and ASIC attacks. A server-side pepper is mixed in before hashing, so even if the database is stolen, breach databases and rainbow tables are useless. Every password is also checked against the Have I Been Pwned database in real time.

AES-256-GCM Field Encryption

Every sensitive data field — names, phone numbers, email addresses, business numbers, credentials — is individually encrypted using AES-256-GCM before it reaches the database. Each data category uses a separately derived encryption key, so compromising one category cannot expose another.

Mandatory Two-Factor Authentication

Every account requires a second form of verification — no exceptions, no opt-outs. We support TOTP authenticator apps, FIDO2/WebAuthn passkeys and hardware keys, and email verification codes. Backup codes are individually hashed. High-security actions like changing your password require TOTP or a passkey.

Immutable Audit Trails

Every data change — create, update, delete — is permanently logged with the timestamp, user identity, IP address, and the exact old and new values. Every login attempt (success and failure) is recorded. These records cannot be edited, deleted, or suppressed — no API exists to modify them, even for administrators.

Database-Level Tenant Isolation

Your data is isolated from every other business using PostgreSQL Row-Level Security policies enforced at the database engine level. Every table is scoped to your organisation. Cross-tenant queries are architecturally impossible through the application layer. Financial data is stored in a completely separate database.

Real-Time Security Monitoring

The platform continuously scans for brute force attacks, credential stuffing, session anomalies, and 2FA abuse. Suspicious IP addresses are automatically blocked. Account lockouts, progressive login delays, and rate limiting work together to stop attacks before they succeed.

The full security architecture

We don't believe in security through obscurity. These are open, auditable standards — knowing the algorithms doesn't help bypass them. The security comes from the keys, not from keeping the method secret.

Password Security

Passwords are the first line of defence. We treat them accordingly — hashed with the strongest available algorithm, checked against known breaches, and enforced with strict policies.

  • Argon2id hashing — memory-hard, resistant to GPU and ASIC brute-force attacks
  • Server-side pepper mixed in before hashing — breach databases are useless even with a full database dump
  • Real-time Have I Been Pwned (HIBP) checking on every password change using k-Anonymity (only the first 5 characters of a SHA-1 hash are sent, never the password itself)
  • 12-character minimum with complexity requirements (uppercase, lowercase, number, special character)
  • Password history — your last 5 passwords cannot be reused
  • 90-day password expiry with enforced rotation
  • Progressive delays between failed login attempts — each failure increases the wait
  • Automatic account lockout after repeated failures

Data Encryption

Sensitive data is encrypted at the field level before it reaches the database. Even with full database access, an attacker gets meaningless ciphertext without the encryption keys.

  • AES-256-GCM authenticated encryption — the same standard used by governments and financial institutions worldwide
  • HKDF (HMAC-based Key Derivation Function) generates a separate encryption key for each data category from a single master key
  • Key categories include: identity (names), contact details (phone, email), billing information, authentication secrets, addresses, credentials, and communications
  • Compromising one key category does not expose data from any other category
  • Every encrypted value uses a unique random nonce — identical plaintext values produce different ciphertext
  • Encryption keys are stored in environment configuration, never committed to source code, and never logged
  • Encrypted fields include: names, phone numbers, email addresses, ABNs, billing emails, TOTP secrets, API credentials, addresses, and communication records

Authentication & Sessions

Session tokens are never stored in plaintext. Every session is bound to a device, enforced with timeouts, and can be revoked instantly.

  • Session tokens are hashed with SHA-256 before database storage — a stolen database reveals no usable tokens
  • Auth tokens are httpOnly cookies — JavaScript cannot access them, preventing XSS token theft
  • 5-minute access tokens with 7-day refresh tokens — short-lived access limits the damage window
  • 30-minute inactivity timeout — walk away and your session locks
  • Device fingerprint binding — sessions are tied to the browser and device that created them
  • Maximum 5 concurrent sessions per user — the oldest session is automatically revoked when you exceed the limit
  • Refresh token rotation — each refresh issues a new token and invalidates the old one, detecting theft if a stale token is reused
  • Explicit session revocation — users and admins can kill any session immediately

Two-Factor Authentication

Two-factor authentication is mandatory for every user on the platform. There are no exceptions and no opt-outs. We support multiple methods to fit different security needs.

  • Every new account starts with email verification codes for an initial 5-day grace period
  • After 5 days, users must upgrade to a TOTP authenticator app (Google Authenticator, Authy, etc.) or a FIDO2/WebAuthn passkey
  • WebAuthn support includes hardware security keys (YubiKey), biometric authentication (Touch ID, Face ID, Windows Hello), and platform authenticators
  • Backup codes are generated for account recovery — each code is individually hashed with SHA-256 before storage, so a database breach reveals no usable codes
  • TOTP replay protection — the same code cannot be used twice within its time window
  • High-security actions (password changes, 2FA configuration, session management) require re-verification with TOTP or a passkey, not just a session cookie

Tenant Isolation

Every organisation's data is isolated from every other organisation at the database level. This is not application-level filtering — it is enforced by the database engine itself.

  • PostgreSQL Row-Level Security (RLS) policies are active on every table containing organisation data
  • Every database transaction sets a session-level organisation scope — the database engine automatically filters all queries to that organisation
  • Every organisation-scoped table has a mandatory organisation_id foreign key with CASCADE delete — orphaned cross-tenant data is structurally impossible
  • Admin and background tasks must explicitly request RLS bypass — there is no default path to cross-tenant data
  • The Finance module operates on a completely separate PostgreSQL database with its own authentication — no shared database connection exists between core platform data and financial data
  • Finance access uses a cryptographically signed, time-limited handoff token with a 30-second expiry — it cannot be replayed or reused

Security Monitoring

The platform doesn't just log threats — it actively watches for them in real time and responds automatically.

  • Continuous audit log scanning every 2 minutes for attack patterns
  • Brute force detection — identifies IP addresses with abnormally high login failure rates and blocks them automatically
  • Credential stuffing detection — recognises patterns of valid-username, invalid-password attempts across multiple accounts from the same source
  • Session anomaly detection — flags sessions that change device fingerprints or exhibit unusual behaviour
  • 2FA abuse detection — identifies accounts receiving excessive verification code requests
  • Account lockout spike monitoring — detects coordinated attacks targeting multiple accounts simultaneously
  • Automatic IP blocking for sustained attacks with configurable thresholds
  • Email alerts to platform administrators for all detected threats

Audit Logging

Every meaningful action is recorded permanently. These logs exist for regulatory compliance, dispute resolution, and forensic analysis. They cannot be tampered with.

  • Every data mutation (create, update, delete) is logged with the user identity, timestamp, IP address, and user agent
  • Old and new values are captured on every update — you can see exactly what changed, when, and who did it
  • All login attempts (success and failure) are recorded with IP address and device information
  • Permission changes, role assignments, session events, and administrative actions are all logged
  • Audit logs are immutable — no API endpoint exists to modify, delete, or suppress any entry
  • 7-year retention to meet Australian financial services regulatory requirements
  • Audit logs are accessible to organisation admins for their own organisation's data

API Hardening

The API layer is the perimeter. Every request is validated, every response is controlled, and every error message is sanitised.

  • Pydantic response schemas on every endpoint explicitly whitelist returned fields — accidental data leakage is structurally impossible
  • Error messages are sanitised — no stack traces, internal paths, database details, or implementation hints are ever returned to clients
  • Rate limiting on all authentication endpoints with progressive penalties
  • Global rate limiting at 1,000 requests per minute per IP address
  • Per-user API rate limiting for authenticated sessions
  • CORS (Cross-Origin Resource Sharing) restricted to configured domains — cross-origin requests from unknown sites are blocked
  • Security headers on every response: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • Request size limits to prevent payload-based denial of service
  • Trusted host validation to block host header poisoning and domain fronting
  • HTTPS enforced in production with automatic redirect

Backup Security

Backups are encrypted at rest with a separate key. A stolen backup file is as useless as a stolen database — ciphertext without the key.

  • Automated database backups on a regular schedule
  • Backups encrypted at rest using AES-256-GCM — the same algorithm used for field-level encryption
  • Backup encryption key is separate from the data encryption key — compromising one does not expose the other
  • Backup integrity verification to detect corruption or tampering
Comparison

How we compare

Security features across the board — not named competitors, just what you typically get elsewhere.

Feature Devalo Most SaaS Tools Australian Regulations Require
Data encrypted at rest ✓ Always Varies Recommended for sensitive data
Mandatory 2FA for all users ✓ Enforced ✗ Usually optional Expected for financial services
Immutable audit logging ✓ Complete ✗ Limited or paid add-on Required for financial services
Data isolated per business ✓ Database level Varies Required under Privacy Act 1988
Australian data residency ✓ Always ✗ US/EU by default Recommended for sensitive data
Separated financial data ✓ Isolated DB ✗ Shared infrastructure Required for ACL holders
Password breach monitoring ✓ Real-time ✗ Rarely offered Not mandated, best practice
Session security & timeouts ✓ Enforced Varies Recommended for all platforms
Real-time threat monitoring ✓ Automated ✗ Manual review or none Best practice for all platforms
Encrypted backups ✓ AES-256-GCM ✗ Rarely encrypted Recommended for sensitive data

Compliance built for Australian businesses

Most business software is built in the US and retrofitted for Australian law as an afterthought. Devalo is designed and operated in Australia, built to meet the Privacy Act 1988, the Spam Act 2003, and Australian Credit Licence requirements from day one.

Privacy Act 1988 Spam Act 2003 Do Not Call Register Australian Credit Licence Right to Erasure Data Residency

Questions about our security?

We're happy to walk you through any of the above in detail. No sales pitch — just engineering.