Security & Data Privacy

This page describes the security features built into Knowledge ERP. For specific compliance or data-processing questions, get in touch — see the bottom of the page.

Tenant data isolation #

Knowledge ERP is multi-tenant: your account's data is scoped to your account at the data layer. Every business record is tied to its owning account and queries are automatically constrained to it, so one customer can never see or touch another's records. This isolation is enforced centrally rather than left to individual screens.

Authentication #

People sign in through the appropriate door for who they are:

• Team members sign in to the app with their account credentials.
• Customers use the portal via a passwordless magic link — no customer password to manage or leak.
• Integrations authenticate to the API with bearer tokens (see below).

Forgetting your password #

Forgot password? on the sign-in page emails a link to choose a new one. The link works once and expires after 15 minutes; asking again simply sends a fresh one.

Three things it deliberately does not do:

• It does not skip your second factor. Setting a new password takes you back to the sign-in page, where you are asked for your code exactly as usual. A reset is a way past a forgotten password, not past two-step sign-in.
• It does not confirm whether an address has an account. The page says the same thing either way, so the form cannot be used to find out who works at your company.
• It does not leave old sessions running. Changing your password signs out every other browser and phone that was still signed in as you, and retires any "remember me" they were holding. If you are resetting because you think somebody else got in, that is the part that puts them out.

If nothing arrives, check the spam folder first — and note that a disabled user is sent nothing at all, by design. An administrator can set a password directly from the Users list.

Two-factor authentication #

Any team member can add a second factor to their own sign-in from My Profile. There are two to choose from:

• An authenticator app — Google Authenticator, 1Password, Authy or any other that reads a standard TOTP QR code. The stronger of the two: nothing to intercept, and it works when the phone has no signal. Turning it on shows a QR code to scan, then asks for one code from the app to prove the pairing worked.
• A code sent to your email address, if your account allows it and you are not an administrator (see below). For anyone without a phone they can pair — no smartphone, a device being replaced, an app they have not installed yet. Each code lasts about four minutes, works once, and there is a limit on how many can be sent to one person in an hour.

From then on, signing in asks for the six-digit code after the password.

Keep the recovery codes. They are shown once, when the second factor is switched on, and each works once. They are the way back in if the phone is lost, wiped or replaced — without them, an administrator has to intervene. Store them somewhere that is not the phone.

The secret behind the codes and the recovery codes are both encrypted at rest, so a copy of the database is not enough to sign in as somebody or to bypass their second factor.

Requiring it

Your administrators always need one, and it has to be an authenticator app. They hold every permission the account has, can issue API keys and change the plan, and theirs is the login nobody shares. That is not a setting.

An emailed code is not offered to them, whatever the account allows. A code and a password reset land in the same inbox, so to anyone who reaches that inbox it is one key rather than two — and an administrator's key opens everything. An administrator who set up an emailed code before being made one finds it dormant: it stops answering, their profile says so, and it would come back if they ever stopped being an administrator.

They are not left short, and nor is the account. They sign in with their password as usual and are sent one last code to that same address; typing it in is what opens the set-up page, where they pair an authenticator app. That code proves the address and nothing else — no other screen opens, the requirement is not met by it, and there is no Set this up later on that route. It is there so that somebody who has only stolen the password cannot walk into an empty set-up page and pair an authenticator app of their own.

For everybody else you choose, under Account Administration → Account Settings → Sign-in security:

Setting	What it means
Not required	Your team can turn it on for themselves, but nobody has to.
For sensitive data only	Everyday work needs no code. One is asked for before API keys, billing, users and roles, exporting your account, or downloading a whole list — and it covers the next 15 minutes.
Every time they sign in	Everyone signs in with a code.

Two more settings sit alongside it:

Setting	What it means
Days to set it up	How long each person may carry on working after they are first asked, before they are stopped. Seven days to begin with, and they see a countdown the whole time. Set it to 0 to stop them straight away.
Allow a code sent by email	Whether someone without an authenticator app may receive a code at their own email address instead. On to begin with. Turn it off to insist on an authenticator app — an emailed code is only as safe as the mailbox, and a password reset goes to that same mailbox. Administrators never get the option either way.

Turning the email option off takes it away from everyone in the account, including anyone who had already chosen it — they are asked to set up an authenticator app instead.

The middle setting is there for shared logins. They are a bad idea — they make your audit trail say one name for several people — but they happen, and a code from a phone nobody in particular owns is not much of a control. So rather than force a choice between security and getting work done, that setting leaves the shop floor alone and asks at the doors where the damage would be: changing who can do what, and taking data out in bulk.

Exporting one invoice or printing one label is not "in bulk" and is never interrupted. Exporting a whole customer, product or invoice list is.

Turning any of this on asks the people it covers to set it up the next time they use the product. It does not lock anyone out on the spot: they meet the set-up page once, can choose Set this up later, and then have the rest of the window — with a banner counting it down on every page — before they are actually stopped. There is always a Sign out on that page too, whatever the countdown says. Each of them gets their own recovery codes.

If somebody runs out of recovery codes, or loses the only phone that had their app, an administrator can reset their two-factor set-up from the Users list and they can enrol again from scratch. The set-up page says this, in the person's own terms: an administrator is told that they are the administrator and that support is the way back, rather than being advised to go and ask themselves.

It covers every signed-in page, not only the ones in the main navigation. Connecting or disconnecting QuickBooks and your email mailboxes, and printing a document, live on their own pages outside it, and the same requirement and the same countdown apply there. Four things deliberately stay open while somebody is meeting it — setting up, confirming a code, accepting the current Terms, and downloading a finished export of your account — because each of those is either the way out or something you are entitled to. Your customers are not affected at all: the customer portal, your booking links and your surveys are opened by the link you sent, not by a staff sign-in, and nothing there ever asks a customer for a code.

Signing in on the mobile app needs an authenticator app specifically. An emailed code cannot be checked there, so someone using email as their second factor signs in on the web.

Changing any of these three asks you for a code first, whichever policy is set today. They are the switches that decide when everybody else is asked, so they cannot be the ones that never ask. Nothing on the page is saved until the code is accepted, and the change is confirmed on screen afterwards rather than saved quietly.

Role-based access control #

Access follows least privilege. Users are granted roles — named bundles of granular, per-resource permissions — and roles can be scoped to specific locations, so people only get the access their job needs. The same permissions gate the reports and dashboards: a report is open only to someone cleared for every kind of data it displays, so an aggregate cannot be a way around the records behind it. See Users, Roles & Permissions.

Infrastructure & hosting #

Knowledge ERP runs on AWS, with security built into the platform:

• Encrypted in transit — all traffic is served over HTTPS/TLS; plain HTTP is redirected to HTTPS and only modern TLS (1.2+) is accepted.
• Web application firewall — a WAF screens incoming traffic with managed rule sets (common exploits, known-bad inputs, SQL injection) plus per-IP rate limiting.
• Network isolation — application servers and the cache run in private networks with no direct internet access; only the load balancer is internet-facing, and internal tiers accept traffic only from the tier above.
• Encrypted at rest — server volumes, the cache, and object storage are encrypted at rest, and the cache is encrypted in transit too.
• Managed secrets — credentials and configuration live in a managed secrets store (never in code or images), retrieved with least-privilege access; the application picks up rotated database credentials automatically.
• Private asset delivery — public files are served through a CDN (CloudFront); the underlying storage bucket itself stays private.
• Auditing & monitoring — load-balancer access logs, network flow logs, and WAF metrics provide an infrastructure-level audit trail, with alerting on anomalies.
• Resilience — the app runs across multiple availability zones behind an auto-scaling load balancer, with zero-downtime (blue/green) deployments.

API & webhook safeguards #

• Tokens act as a person — every API token belongs to a user or a service account and can never do more than they can, so revoking someone's permissions (or removing them entirely) narrows every key they hold at once.
• Scoped tokens — API tokens can additionally be limited to specific modules with read-only or read/write access, so an integration only reaches what it should. A token's scope can be narrowed later without reissuing it.
• Service accounts — a token-owning identity that cannot sign in anywhere, so a long-lived integration neither depends on an employee's account nor gives anyone a way in. Capped per plan tier and consuming no seat.
• Module gating — every request is checked against your subscription, the token's scope, and the owner's own permissions. The API and the admin panel answer from the same policies, so there is no second set of rules to keep in step.
• No cross-module side doors — a limited token is also refused the endpoints that span every module (webhooks, automation, reports, the user directory) and the mobile endpoints, because no per-module grant can describe them. Those need a full-access token. See what a limited token can and cannot do.
• Rate limiting — requests are capped per plan to protect availability.
• Signed webhooks — outgoing webhooks are signed with an HMAC-SHA256 signature so your systems can verify they genuinely came from Knowledge ERP.

See API: Getting Started and Webhooks.

Payments #

Knowledge ERP records how a payment was received (cash, check, credit card, bank transfer, etc.) but does not collect or store raw card numbers. Card processing is handled outside the ERP by your own payment processor. The platform's own subscription billing is processed by Stripe; no raw billing card data is stored in your ERP data.

Audit trail #

Meaningful changes are recorded with who made them and when, across the app and the API, and most actions can be undone. This gives you accountability and a way to investigate or reverse changes. See Change History & Undo.

Your data #

• Recoverable deletes — major records are soft-deleted, so an accidental deletion can be recovered rather than lost outright.
• Your data is yours — an account administrator can take the whole lot at any time from Account Administration → Export your data: one zip holding a CSV per table (deleted records included), every uploaded file, and a manifest. That includes your audit trail — who changed what, and when — and your support tickets and their messages. Credentials are left out — password hashes, session and API tokens, and integration secrets. Records are also readable one at a time through the REST API.
• One click starts it. Prepare my export asks for nothing else — it costs nothing to run and deletes nothing, so there is no confirmation step in the way. Asking again while one is still building tells you so instead of starting a second copy.
• Exports are built in the background, so a request appears on that page as Queued straight away and becomes a download when it is ready — a few minutes for a large account. Past exports stay listed with the time they were asked for and who asked, and keep a download button for as long as the archive is on disk. A link is emailed as well.

Questions about security or compliance? #

Have specific requirements — data processing, residency, or compliance questions? We're happy to discuss them. Reach out to your Knowledge ERP contact and we'll work through your needs.