Security Policy

Encryption in transit

All communication between your device and Nivaronix is encrypted using TLS 1.2 or higher. That covers:

• Login credentials
• Sensitive data transfer
• API communication
• Scan results and reports

Authentication and access control

• A minimum password length of eight characters, stored only as a bcrypt hash. We do not impose composition rules, and we do not check your password against known-breached lists — so please use a password manager
• Session-based authentication using a 256-bit random token, held in a cookie that is HTTP-only, Secure and SameSite=Strict, and stored on our side only as a hash
• Rate limiting on failed login attempts, by IP address and by email address. Note this is throttling, not lockout — repeated attempts are slowed and refused, and an account is never locked out of its own access.
• Sessions expire 24 hours after sign-in. That is a fixed lifetime, not an inactivity timeout — a session does not end early because you stopped using it, so log out on a shared device. Our own admin console, which is not part of your account, additionally times out after 30 minutes idle
• Role-based access control for platform features, enforced per organization on each request rather than only in the interface

Separation between customers

Every request is scoped to the organization it belongs to, on the server, from the identity you authenticated as — not from an identifier in the request. An API key can only ever act on its own organization, and an organization ID supplied in a request body is ignored rather than honoured.

Asking for another organization's record returns the same not-found answer as asking for a record that never existed, so the response cannot be used to work out what else we hold. This is the part of our security posture with the most tests behind it: a dedicated cross-tenant suite covers assets, findings, incidents, reports, imports, webhooks, client workspaces, API keys and SSO, and it is run on every change.

Audit records

Security and administrative actions are written to an audit log that the database itself refuses to let anyone rewrite. Append-only is enforced by a database trigger rather than by application convention, so a bug in our code, a stolen administrator credential, or a direct database session cannot quietly edit history. There is one deliberate exception: a data-subject erasure request under GDPR Article 17 can delete your rows, because an audit log that survives a valid erasure request would break a right we are obliged to honour. Records of consent to scan a domain are kept under Article 17(3)(e) and are never deletable.

Storage and monitoring

User data is stored in a managed database with restricted access. Backups run nightly, so a failure could lose up to 24 hours of data. There is no automatic failover and no second region — our reliability page states the architecture in full. Application activity is recorded in security event logs; we do not run network-level intrusion detection.

Scanning and your data

When you submit a domain for scanning, Nivaronix:

• Only reads what any visitor to the site can read — no credentials, no authenticated areas, and nothing that is not already served publicly
• Requests your homepage once, plus robots.txt and sitemap.xml, and reads the response body to check meta tags, canonical links and the technologies in use. It does not follow redirects and it does not crawl beyond that page. Broken-link checking, which does follow links across your site, runs only on an asset you have verified and put under monitoring
• Does not keep a copy of your page. We store the findings, not the HTML — though a finding quotes the specific tag or link it is about, so short excerpts of your markup are retained as evidence
• Keeps scans run from your account inside your organization, for as long as your plan's history window. A scan run from the public scanner without logging in belongs to no account: it is stored unattached for 7 days and then deleted, unless you choose to share it by link, in which case it stays reachable by anyone holding that link until you delete it

Where an incident is analyzed with AI assistance, the domain and finding details are sent to our language-model provider so the analysis can name the affected host — an analysis that cannot say what it is about is not useful. Our Privacy Policy lists every provider that receives data, exactly what we send them, and how long scan and security logs are kept.

Remedy Engine: automation and approval

Remedy Engine can act on a finding through a connected protection provider. What happens next is decided by a fixed set of rules, evaluated in order, for every proposed action:

• Your protection policy or plan does not allow automatic remediation, the action is not on your policy's allowed list, or your organization has switched off automatic protection with the kill switch — the action is denied or held for a human, never executed
• No protection provider is connected, or the connected provider cannot perform the action — it is recorded as a recommendation only, nothing is executed
• The action's risk level exceeds your policy's auto-approval ceiling, or your plan does not include automatic remediation — it waits for a human with approval permission before it runs
• Only when a policy explicitly allows the action, its risk is within your policy's auto-approval ceiling, your plan includes automatic remediation, and the kill switch is on, can it execute without a human

A completed remedy can be rolled back, and every decision records the reasons that produced it — not just the outcome — so you can see why an action ran automatically, waited for approval, or was only recommended.

Standards we work to

Nivaronix follows industry security best practices and standards, including:

• Parameterised database access throughout and schema-validated request bodies, which is what closes the injection classes in the OWASP Top 10
• Restrictive security headers on our own surfaces — the same ones we check yours for — and a scanner that refuses to be pointed at private network addresses
• Secret scanning on every pull request and every push, and container image scanning at the point of release. Image scanning covers operating-system packages only: it does not see a vulnerable npm or pip dependency, and we do not currently run a dependency vulnerability scanner or an automated code-analysis tool
• Passwords stored only as bcrypt hashes; application containers run as a non-root user

To be explicit about what that does and does not mean: Nivaronix holds no third-party security certification. We have no SOC 2 report and no ISO 27001 certificate, we are not currently undergoing an audit for either, and nothing on this site should be read as claiming otherwise. The practices above are what we do; they have not been examined by an outside auditor.

What our numbers do and don't cover

Uptime and status figures on our status page are computed from what our monitors actually observed — where a monitor has no data for a period, we show that gap rather than filling it in. See our methodology page for how each check works and what it does and does not verify, and findings for what our scanner checks for and how it scores results.

A scan reads what our scanner can observe from outside your systems at the moment it runs; it is not a substitute for a manual security review or a third-party penetration test, and a clean result does not mean every vulnerability class has been checked.

If there is an incident

In a security incident we act immediately to investigate, contain and remediate it. Where an incident affects your data, we notify you in accordance with applicable law.

Your part

You are responsible for keeping your account credentials confidential:

• Use a strong, unique password
• Never share your login credentials
• Log out when finished, especially on a shared device
• Report suspicious account activity immediately

Reporting a vulnerability

We appreciate researchers who report vulnerabilities responsibly. Email admin@nivaronix.com with the details, and we will investigate and work with you to resolve the issue. The same address is the right one for any other security concern or question.

Nivaronix is operated by Pravin Gyawali, based in Butwal, Nepal. Reports are handled by the operator directly rather than by a staffed security team, so please allow a reasonable time for an initial acknowledgement.