Security

Pingmon holds a map of your network, which makes it worth protecting properly. This page describes how it actually works, rather than listing badges.

Tenant isolation

Each organisation has its own subdomain and its own data. Isolation is applied automatically at the database layer to every query, rather than depending on each screen remembering to filter by customer — the class of mistake that causes most cross-account data leaks. A session issued for one organisation is rejected on another's subdomain.

Authentication

• Two-factor authentication is mandatory for password accounts. Enrolment happens on first sign-in and cannot be skipped, with single-use recovery codes for a lost device.
• Single sign-on is available if you would rather your own identity provider held the accounts, in which case it also holds the second factor.
• Passwords are hashed, never stored or logged. We use a length-first policy rather than composition rules, which push people towards predictable substitutions.
• Sign-in is rate limited per account and per network, so a stolen password cannot be brute-forced quietly and a password-spraying attempt trips a limit even when no single account does.

Access within your organisation

Users are added by invitation, never by an administrator setting someone else's password — so no one but the account holder ever knows their credentials. Roles separate people who need to read from people who can change things.

Credentials you give us

Device passwords, SNMP community strings and API keys are encrypted at rest. Tokens for invitations, password resets and agents are stored only as hashes, so a database copy cannot be replayed into access.

What we log

Sign-ins, failed attempts, two-factor changes, role changes and administrative actions are recorded so you can answer "who changed this, and when".

Reporting a problem

If you believe you have found a security issue, please contact us directly rather than filing it publicly. We will acknowledge and keep you updated.