Security

In short

• The agent only makes outbound HTTPS connections. It opens no ports and does not allow remote control in this version.
• Each machine has its own key and signs every report. In the cloud we only store public keys.
• Agent updates are signed with a key that is not in the cloud, and they are verified before they are installed.
• Each account is isolated from all the others. Protected passwords, two-step verification and an action log.
• We hold no security certifications. We tell you what we do, and also what we don't do yet.

How it works

You install a small agent on each machine. The agent measures the machine's health and sends it to the Vitalnodo cloud. You see it in your browser. Data always travels in one direction only: from the machine to the cloud.

The agent on the machine

• Outbound connections only. The agent talks to the cloud over HTTPS, like a browser. It opens no ports, needs no VPN and you don't have to touch your client's router.
• No remote control in this version. The agent we distribute contains no terminal or remote desktop, and the cloud rejects those requests. Nobody can run commands on the machine from Vitalnodo.
• Read-only. It measures the machine's health and security posture, but it doesn't change its configuration or install system updates.
• It validates the server. It checks the TLS certificate against the system's trusted roots. It doesn't accept unencrypted connections.
• It protects its files. Its configuration and private key are stored in a folder that only the system can access (root or SYSTEM, plus Administrators on Windows).
• It collects the bare minimum. No files, documents, browsing, keystrokes or screenshots. The details are in The data Vitalnodo collects.

Each machine's identity

When it is installed, each machine creates its own Ed25519 key pair. The private key never leaves the machine. The cloud only stores the public key.

• Every report is signed. The signature covers the method, the path, the time and a SHA-256 digest of the content. If anyone changes a single byte along the way, the cloud rejects it.
• Replay protection. The cloud rejects submissions that are more than 5 minutes off, and each report carries a unique identifier: if it arrives twice, it is counted only once.
• A database leak is not enough to impersonate machines. It only holds public keys and digests of the install keys, never a reusable secret.
• The machine identifier doesn't travel in the clear. Only a SHA-256 digest of the board or system identifier is sent.
• Install keys under your control. You can revoke them or give them an expiry date or a maximum number of uses. On the MSP plan you can require manual approval for each new machine.

Updates and installers

• Signed updates. Each agent version is published in a manifest signed with Ed25519. The private publishing key lives only on the machine where we build, outside the cloud. Even if someone took over our server, they couldn't sign a fake version.
• Verification before installing. The agent checks the manifest signature with its built-in public key and the SHA-256 of the downloaded file. If anything doesn't match, it installs nothing.
• Automatic rollback. If a new version fails to report within 5 minutes, the agent restores the previous one.
• Verified installers. The Windows, Linux and macOS install scripts check the binary's SHA-256 before installing it. If the install key isn't valid, the installer stops with a clear message, never halfway through.
• Notice before installing. The installer shows what data is sent and asks you to confirm that you manage the machine with its owner's authorization.

Your account

• Protected passwords. We never store them in the clear: we store a PBKDF2-SHA256 digest with 100,000 iterations and a random salt. We require at least 10 characters and reject the most common ones.
• Attempt lockout. After 10 failed attempts in 15 minutes for the same email (or 30 from the same IP), access is temporarily locked. Error messages don't reveal whether an email is registered.
• Two-step verification (2FA) with any TOTP app. The secret is stored encrypted with AES-GCM.
• Secure cookies. The session uses an HttpOnly, Secure and SameSite=Lax cookie that expires after 14 days at most. Changes require an origin check and an anti-CSRF header.
• Audit log. We log sensitive actions (sign-ins, 2FA, invitations, install keys, machines added and removed, plan and settings changes, exports and deletions) with user, IP and date. You can see it in the app itself.
• Email notices when someone signs in from a new IP, 2FA is turned off or an install key is created.
• Roles and scope. Owner, administrator, technician or read-only, and access limited to certain clients if you need it.

Isolation between accounts

Every database query is limited to the account of the signed-in session. The server sets the account identifier, never the browser. Identifiers are random, not sequential, and the icons you upload are only served to users of your account.

The website

• Strict Content Security Policy (CSP): the browser only runs code served by Vitalnodo. No third-party scripts, fonts or styles.
• No third-party analytics or advertising.
• HTTPS is mandatory (HSTS), the page cannot be embedded in other sites, and we don't send the referring address to other sites (Referrer-Policy: no-referrer).
• Data is shown on screen as text, never as code, to prevent injection.

Infrastructure and backups

• Vitalnodo runs on Cloudflare (Workers, D1, Durable Objects and R2). The database and storage are in the Eastern North America region (USA), and traffic goes through Cloudflare's global network.
• According to Cloudflare, object storage (R2) is encrypted at rest. On top of that, we separately encrypt the most sensitive data, such as the 2FA secret and the purchase license.
• Backups and recovery: the database can be restored to any point in the last 30 days (D1 Time Travel). That's why anything deleted may remain in those technical backups for up to 30 days.
• Only the service operator has access to the production infrastructure. The server signing keys and encryption secrets are stored as Cloudflare secrets, outside the database.

Security reviews

In October 2026, before launch, we carried out two independent internal audits of the code and configuration. The issues they found were fixed before the service was published.

These are internal reviews: they are not an external audit or a certification.

What we don't have yet

• Certifications such as ISO 27001 or SOC 2.
• A penetration test performed by an outside firm.
• A service level agreement (SLA) with service credits.
• Remote access. It is built but turned off. We won't turn it on without an independent security review.

No system is invulnerable. If you find a flaw, we want to know: see how to report it.

If an incident happens

1. We contain the problem: we revoke access, end sessions or turn off the affected feature.
2. We notify you by email, without undue delay, aiming to do so within 72 hours of confirming the incident. We tell you what happened, which data was affected, what we have done and what we recommend you do. If we don't know everything yet, we report in stages.
3. We notify the authority when the law requires it. In Peru, the National Authority for Personal Data Protection within 48 hours in the cases set out in its regulations.
4. We learn: we fix the root cause and check that it doesn't happen again.

If you suspect unauthorized access to your account, email us right away at seguridad@vitalnodo.com.

Report a vulnerability

If you think you've found a security flaw in Vitalnodo, email us at seguridad@vitalnodo.com. We also list it in our security.txt.

Our commitment

• We reply within 5 business days at most.
• We keep you posted while we fix it.
• If you wish, we credit you when we publish the fix. We don't have a monetary bounty program for now.

Safe harbor

If you research in good faith and follow these rules, we won't take legal action against you or ask anyone else to, and we'll consider your research authorized:

• Only use accounts and machines that are your own. Don't access, change or delete other people's data; if you come across it, stop and let us know.
• No denial-of-service testing, mass messaging, social engineering or physical attacks.
• Don't exploit the flaw beyond what is needed to demonstrate it.
• Give us a reasonable amount of time to fix it before making it public. We'll agree on it with you, usually up to 90 days.

Contact

Security

seguridad@vitalnodo.com

Privacy

privacidad@vitalnodo.com

Support

soporte@vitalnodo.com