Privacy and data handling
NoCert stores certificates, which are public documents, and the places it saw them. It has no use for your private keys and never asks for them.
The privacy policy, terms and DPA are the binding documents. This page explains what the product actually does.
Your certificates
Section titled “Your certificates”NoCert keeps the certificate itself, and where each one was found: an IP and port, a file path on a host, or a Kubernetes secret. From the certificate it derives everything you see in the app, including expiry, chain and compliance results.
A certificate is public by design. It is what a server hands to anyone who connects.
Private keys
Section titled “Private keys”NoCert never stores a private key, never transmits one, and never asks you for one.
A Sentinel that finds a key file next to a certificate reads its mode and reports a single fact: whether any group or other bit is set. Telling a key apart from any other .pem beside the certificate means reading the first kilobyte and looking for a PRIVATE KEY header, which the Sentinel discards. Neither the contents nor the path is sent, and every certificate it does send passes a structural check that rejects key material.
The match is by filename, so a Let’s Encrypt layout, where privkey.pem sits next to fullchain.pem, produces no warning either way.
The Kubernetes scan is the case that deserves the detail. Kubernetes cannot hand out part of a secret, so a TLS secret arrives whole in the Sentinel’s memory, private key included. Only the certificate keys are read back out of it. That boundary is a few lines of code in an open source agent, so you can check it rather than trust it.
Credentials you give us
Section titled “Credentials you give us”Some features need a credential from you. DNS connector tokens, single sign-on client secrets and identity tokens, and stored organization settings are encrypted at rest with AES-256-GCM.
Two things are not encrypted, and you should treat them accordingly. Slack, Teams and Discord webhook URLs are stored as given and are readable by any operator in your organization, because the app has to show them back to you when you edit a target. Kubernetes cluster credentials never reach NoCert at all: they stay on the Sentinel’s host, in files you control.
People
Section titled “People”NoCert stores the email addresses of your members, their role, and their sign-in activity. A member you add starts with their email address as display name, and one your identity provider creates carries whatever name it supplies.
The activity log keeps entries for 12 months, including the recipient addresses of alerts that were sent. See Activity log.
Deleting things
Section titled “Deleting things”Deleting a domain stops its discovery. Certificates and endpoints stay unless you ask for them to go, and even then anything shared with another of your domains is kept. Deleting a Sentinel revokes it and drops the filesystem, local-listener and Kubernetes findings it reported. Certificates and endpoints it observed on the network stay, since they are what your estate was serving rather than that Sentinel’s private record.
When a trial ends the organization becomes read-only for 30 days, and after a subscription is cancelled for 60, so you can still read and export. After that the organization and its data are deleted.
If you need data removed sooner than that, ask.