Security practices

Everything on this page describes what the product does today. If it is not built, it is in the "not yet" list at the end.

Signing in

• Passwords are stored only as salted one-way hashes (bcrypt). Changing a password needs the current one and is recorded in the audit log.
• Sign-in attempts are rate-limited per network address to slow down password guessing.
• Console sessions expire after 12 hours. Removing a person through single sign-on or automatic provisioning ends their sessions straight away.
• Single sign-on for organisations: SAML 2.0 and OpenID Connect, with domain verification. Admins can require single sign-on for everyone, keeping named emergency ("break-glass") admins.
• Automatic provisioning with SCIM 2.0: people and groups are created, updated and removed from your identity provider, and groups can map to roles.
• Sign-in with an existing work account (Google, Microsoft, LinkedIn, GitHub) for individuals and small teams. An existing account is linked only when both sides have confirmed the e-mail address.

Keeping secrets and data safe

• The credentials you give us to connect channels and tools are encrypted with AES-256-GCM using a key unique to your organisation. That key is itself encrypted with a master key kept outside the database, so a copy of the database alone does not reveal them.
• Secrets are decrypted only at the moment we call the outside service. Nothing in the product shows a stored secret back to a person, including our own administrators.
• API keys are stored only as hashes; you see the full key once, when you create it.
• All traffic to the service is encrypted in transit (HTTPS).
• Messages we receive from connected services (webhooks) are checked against a signature or a secret key before they are accepted; unsigned messages are refused.

Who can see what

• Organisation isolation: every record belongs to one organisation, and every request is checked against the signed-in person's organisation.
• Roles and permissions per module (none, read or write). In the CRM a role can see all records, its team's, only its own, or look up one record at a time; fields can be hidden, masked or read-only. Look-ups are rate-limited.
• Exports, imports, deletions and bulk changes are written to an access log, and field changes keep a history.
• Audit log: security events such as password changes and support access are recorded, and your admins can read your organisation's log.
• Our own support access to your organisation is time-limited (5 minutes to 8 hours), needs a written reason, is recorded in the audit log and is visible to you. Stored secrets stay unreadable even then.

Video and webinars (UniCast)

• Videos are private by default. Share links can have an expiry date, a password and a list of websites allowed to embed them; setting a video back to private turns every link off.
• Video files are delivered through short-lived signed links, not permanent public addresses.
• Nothing is published until its content check passes or a reviewer in your organisation approves it.
• Authenticity seal: each organisation has its own digital signing key. A published video is sealed, and anyone can check online that it came from you and has not been altered since.

Payments

• Card details are handled only by our payment provider; we never see or store card numbers. Payment notifications are checked against the provider's signature, and payment actions are rate-limited.

Testing, backups and changes

• Continuous testing: 100+ automated checks run against the live service every 10 minutes, using test organisations only. They cover sign-in, roles, keys, isolation between organisations, the audit log, billing and every product area, and alert us when something fails.
• A full regression run, including tests too risky for the live service, runs every night on a throwaway server.
• A consistent copy of the database is taken before every release, without stopping the service.
• Changes to sign-in, access control and payments get a separate review before release, and fixes from those reviews are made before the change ships.

What we do not have yet

• No third-party security certification (for example ISO 27001 or a SOC 2 report) yet.
• No independent penetration test yet.
• A single hosting region; no second region to fail over to.
• No built-in two-step verification for password sign-in yet. Organisations that need it can require single sign-on and use their identity provider's multi-factor sign-in.
• Public beta: we are a small team, and there is no round-the-clock security operations centre.

Found a security problem? Write to hello@unisonai.com with the details. Please give us a reasonable time to fix it before you share it publicly.