Security

What this page is not

Nifty Connect holds no ISO 27001, SOC 2 or equivalent third-party certification, and this page claims none. Nothing here has been audited by an external assessor. What follows is a description of measures that are built and running, written so that you can ask us to demonstrate any of them.

Accounts and sign-in

• Passwords are hashed with argon2id, with parameters following current OWASP guidance. Plaintext passwords are never stored or logged.
• Optional time-based one-time password (TOTP) multi-factor authentication, with recovery codes. The TOTP secret is encrypted with AES-256-GCM at the application layer before it is written, so the plaintext secret never reaches the database.
• Progressive lockout. Consecutive failed sign-ins are counted and the account is refused for a period regardless of whether the password is later correct.
• Sign-in responses are deliberately uniform, so the response does not reveal whether an email address has an account.
• Changing a password or completing a reset revokes every active session, and an administrator can revoke other sessions from the account screen.
• The sign-in rate limit is shared across application instances and fails closed: if the limiter cannot be reached, sign-in is refused rather than allowed through unmetered.

Separation between customers

• Every organisation is isolated at the database and API layer, not by filtering in the interface. A request carries the scope it is allowed to act in, and the query is bounded by it.
• Roles and entitlements are enforced server-side on every request. Hiding a button is never the control.
• Resellers see only the customers assigned to them, scoped server-side. A reseller dashboard is not a filtered view of everything.
• Platform administration is a separate role with its own permissions, and it does not grant the ability to act inside a customer’s workspace or read their content.
• Administrative actions are written to an audit trail.

Meetings

• Meeting media is carried over encrypted transport. Guests join by link, enter a name and can be held in a waiting room for a host to admit.
• A host can lock a meeting, admit or deny individual participants, mute, change roles and remove people.
• Meetings can be set to invited participants only, and can require a passcode. Passcodes are stored hashed.
• Participants are told when a meeting is being recorded.

Recordings and transcripts

Recording, transcription and AI summarisation are not enabled in the live service. They are implemented and tested, but no object store has been provisioned for them yet, so nothing is being recorded, transcribed or summarised today. What follows describes how they behave once a store is provisioned — not something currently running.

• Recordings belong to the organisation, are held in object storage, and play back through short-lived presigned URLs issued per request. There is no publicly-shareable recording link.
• The recorder is granted a presigned upload for a single object key with a duration cap, rather than broad write access to storage.
• Transcription and AI summarisation sit behind a provider abstraction, so the platform is not locked to one vendor. Which provider is in use, and what that means for your data, is something we will set out for your organisation on request — ask us.

The application itself

• HTTPS only, with HSTS (max-age=31536000; includeSubDomains; preload) and automatic certificate renewal. Plain HTTP redirects.
• A per-request Content Security Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a referrer policy and a permissions policy. The one framable surface is the Microsoft Outlook add-in, which is allowed to be embedded by Outlook’s own origins and nothing else.
• The public marketing domain cannot reach the customer, reseller or platform administration interfaces at all: those paths are refused at the reverse proxy and again in the application, by hostname.
• The reverse proxy serves no files from disk — there is no file-serving directive — so no configuration file, source file or backup is reachable over HTTP.

Backups and recovery

• The database is backed up on a schedule, each backup recorded with its size and SHA-256 checksum, and written under a temporary name so an interrupted backup never appears usable.
• Restores are rehearsed, not assumed: a backup is restored into a separate empty database and the record counts, schema version and tenant relationships are compared against the live database. The most recent rehearsal passed.

Reporting a vulnerability

Email support@niftyit.co.za with “security report” in the subject. Tell us what you found and how to reproduce it. Please do not test against other customers’ data or run denial of service attempts.