How the platform protects credentials
We build an identity platform, so this page describes controls that exist in the software rather than intentions. Each of these is implemented today.
Passwords are never stored
Passwords are hashed with bcrypt and only the hash is kept. We cannot read your password, and support cannot recover it for you - a reset replaces it. Repeated failed sign-ins are counted and the account is locked out, and request throttling applies on top of that.
Multi-factor and passwordless
Time-based one-time codes (TOTP) and WebAuthn passkeys are both supported, on every plan rather than as a paid upgrade. Recovery codes are issued so that losing a device does not lose the account. TOTP secrets are encrypted at rest with a key held outside the database.
Enterprise sign-in
SAML, OIDC and LDAP are supported, so an organisation can keep its existing identity provider as the source of truth. Tokens held for federated sessions are encrypted at rest with a separate key.
Tokens stay out of the browser
The web console authenticates through a backend-for-frontend, so access and refresh tokens are held server-side against a session rather than in JavaScript-readable storage. Script injected into the page cannot read a token that is not there.
Tenant isolation
Data is scoped to a tenant and access is checked against your membership and roles on every request, not just at sign-in. Billing gateway accounts are scoped to a tenant at the database index level.
Card details never reach us
Payments go directly to Stripe, PayPal or Braintree. We store a reference to your customer record with the processor and nothing more - no card numbers pass through or rest on our servers.
What we have not done yet
Stating this plainly is more useful to you than silence, and an enterprise reviewer will establish it in the first call anyway.
- No SOC 2, ISO 27001 or comparable certification. We hold none, and we do not display badges for audits that have not happened. If your procurement process requires one, we are not ready for you yet.
- No independent penetration test has been carried out on the platform.
- No public status page or availability monitoring, which is why the terms do not promise an uptime figure.
- No bug bounty programme. We will still take a report seriously and credit you, but we cannot currently pay for one.
- Formal data retention periods are not yet defined for security logs. See the privacy policy.
Reporting a vulnerability
Email security@finomium.co. Please include enough detail to reproduce the issue - a request, a sequence of steps, or a short proof of concept.
What we ask: give us a reasonable chance to fix it before publishing; do not access, modify or keep data belonging to anyone else; and do not run denial-of-service or high-volume automated scanning against production. Testing against your own account and tenant is welcome.
What you get: an acknowledgement that a person has read it, an honest assessment of severity and timeline, and credit when it is fixed if you would like it. Acting in good faith within the boundaries above will not be treated as a breach of the terms of service.
Your part
- Turn on multi-factor authentication or register a passkey. It is the single biggest difference you can make to your own account's security, and it costs nothing here.
- Review active sessions and revoke ones you do not recognise - IP address and browser are recorded so you can tell them apart.
- Use scoped personal access tokens for automation rather than your own password, and rotate them.
- Remove people from your tenant when they leave.