Who can reach your customer data?

In a lot of software, who may see what is decided where the screen is built. That works as long as every screen gets it right. If one page forgets the check, another company's data is on it, and you find out when someone reports it.

In Nermio that boundary sits a layer lower: in the database. Every table with customer data has rules saying which rows a logged-in account may see, and the database applies those rules to every single query, whichever screen or route asks it. So a bug in the application can produce an error, but not another organisation's data. Visitors without an account have no read access to those tables at all.

Inside your own organisation, you decide the rest. There are four roles — owner, manager, user and read-only — and someone on “read-only” can't change anything by a side route either: it's the same layer that enforces it.

A log nobody can edit

Nermio keeps two logs. One records what is done in your environment, and by whom. The other records what happens to accounts: login attempts, setting up a second factor, a password change. They're kept apart, so during an incident you can read one without fishing it out of the other.

What matters more is what can't be done with it: a line that's in there can't be changed and can't be deleted. That isn't a policy but a property of the table — the database refuses, even when the request comes from our highest administrator role. A log the administrator can tidy up is not a log.

We don't look over your shoulder quietly

Sometimes one of us has to look into your environment to solve a problem. That's possible, but not unnoticed and not unlimited. To do it, a member of staff starts a support session and has to give a reason. That session has an end — fifteen, thirty or sixty minutes, never open-ended — and closes automatically when the time is up. One member of staff can't have two sessions open at once, so “I was still logged in somewhere” doesn't exist.

At the start it's decided whether the session may only read or also change; looking is the default. Deleting is never possible during a support session — there is no route for it at all, not even with the right role. It also isn't logging in as you: the log doesn't show your name, it shows the staff member's, with the session alongside.

And you can read it back. The owner of an organisation has read access to their own support history: which sessions there were, with what reason, when, and what happened in their environment during that session. That isn't an extra; it's what makes support access explainable.

Logging in

We don't keep your password. It goes to Supabase Auth encrypted and can't be read back after that — not by us, and not during a support session. So a forgotten password can only be reset, never looked up. Someone impersonating you who rings to have their password read out doesn't get it, because it isn't possible.

Logging in and password resets have a limit: too many attempts within a few minutes are refused. That counter lives in the database and not in one server's memory, because with several servers alongside each other an attacker would barely notice a limit at all.

After your password there's always a code from an authenticator app, for every account: yours, your colleagues' and our own staff's. The check is per session, not per account. Not “this account switched 2FA on once”, but “this session got through it” — otherwise a stolen password would still be enough.

You can enrol two authenticators: your phone and a spare, a password manager on your laptop for instance. That's there for the day a phone goes in the water. With a spare you log in on the other device and set up a new handset yourself. Without one you can't, and then you have to ask us: only we can reopen a second factor, not the administrator of your own organisation. That's deliberate, because otherwise a whole team's second factor is only as strong as the least careful person in it. More than two isn't possible, for the opposite reason: every extra device is one more place your account can be opened from.

Where your data sits

On a Postgres database at Supabase, on servers in Frankfurt (eu-central-1), so inside the EU. The traffic between your browser and Nermio goes over an encrypted connection.

Your data stays yours, and you get it out yourself: under Settings there's an export button per type that gives you your companies, contacts, deals, tasks, your timeline and your notes as CSV. You can do that any day your account is running, not only when you leave, and anyone on your team can, including read-only users. It keeps working for thirty days after you stop; changing anything doesn't.

What we don't claim

Nermio is a young product, and on a security page that's relevant. We have no ISO 27001 or SOC 2 report, and no external penetration test. Software that shows logos like that without having them is the kind of claim you only check once something goes wrong.

So what's written here isn't a certificate but a description of what's in the code and the database. If you find a weak spot, we'd like to hear it at info@nermio.com with “beveiliging” in the subject line. Reporting it is more useful than keeping quiet, and we take a report seriously.