How to set up Nota, enroll your people and work with your records. The dashboard calls a supervised person a custodian, so these guides do too.
| Role | What it can do |
|---|---|
| Owner | Everything an admin can do, plus subscription changes, cancellation, and identity provider and directory changes. |
| Admin | Manages custodians, signup links, group mappings and policy. Can't read messages or approve access. |
| Records Officer | Approves access requests and exports records. |
| Supervisory Reviewer | Requests access and searches approved records. |
| Custodian | Sees their own enrollment status and linked devices. |
Each access request takes at least three people: one to request and two to approve. A person may hold more than one role. Role changes take effect on their next request.
Each custodian enrolls themselves. Nota never contacts them, so your team runs the rollout.
Each custodian in Directory mode has an enrollment deadline, 7 days by default, which you can change in settings. After the deadline, Nota opens an enrollment-overdue gap until the device is covered.
When capture stops for someone, their page tells them to remove the linked device from their app.
| Status | What it means |
|---|---|
| Covered · active | The linked device is capturing, and traffic has been observed. |
| Covered · idle | The device is connected and has proven it's alive, with no recent traffic. |
| Degraded (unproven) | The device is connected, but liveness hasn't been fully proven yet. |
| Capture gap | Capture is interrupted. Messages may exist that aren't being captured. |
| Pending enrollment | No linked device is capturing for this person yet. |
| Account dormant | The person's messaging account has been inactive. |
| Unenrolled | Capture has stopped for this person. |
| Decommissioned | The person's records are no longer active in capture. |
Every gap records a start, an end or "open", a cause and a remediation reference. Check the Gaps view regularly: Nota doesn't send gap notifications yet.
For the limits of what coverage proves, see the Trust center.
When a person leaves the custodian group, capture continues for a 30-day hold. An admin can end the hold early, and then the person is unenrolled.
Nota doesn't keep a search index. Records are decrypted for each search, and nothing derived from them is stored. Hosted review is off for organizations that hold their own key; see Customer-held keys.
A records officer exports the records covered by an approved request. Nota's team then delivers the bundle to your records officer. Self-service download is on the way Planned.
events.jsonl: one entry for each event, with its decrypted message.attachments/: each attachment, named by its hash.proof.json: the signed proof that lets anyone check the rest.Run Nota's verifier on the bundle's folder. It needs no network connection or Nota account, and it confirms that each exported record matches what was captured and sits where the chain says it does. A bundle proves that the records it contains are authentic. It doesn't prove that the set is complete.
By default, Nota holds the key that protects your archive. You can hold it yourself instead. Then Nota can't read your stored records. Any change shows up when you verify, and with a retention lock nobody, Nota included, can delete them before the term ends. Capture still handles each message in memory while it archives it, under separate controls, so a customer-held key protects what's stored, not that step.
Customer-held keys are available with limits: for keys in AWS KMS, with Standard or Attested capture. With Attested capture, capture's keys open only after the environment proves it's running approved software. Your own key never opens for Nota. They aren't available with Google Cloud KMS or hardware security modules, which are coming.
You choose the mode when your organization is created. It can't be changed afterward, and organizations that already exist can't move to a customer-held key yet.
| Mode | Who holds the key | If you turn the key off |
|---|---|---|
| Held by Nota | Nota | Nothing for you to turn off. |
| KMS key | You, as a symmetric key in your own AWS KMS account. Nota can use it only to protect new records, not to open them. | Capture stops and a gap is recorded. See Pausing and resuming capture. |
| Public key | You, as a private key in your own key system. Nota keeps only the public key. | Capture continues, because Nota never contacts your key system. You can't read your records until you restore the key. |
In either customer-held mode, withdrawing your key makes your records unreadable. A destroyed key can't be recovered by you or by Nota.
We recommend a KMS key that AWS KMS creates, with automatic rotation turned on. Rotation keeps the same key and every earlier version of it, so older records stay readable and there's no old key for you to keep. A KMS key with imported key material or in a custom key store also works, but it can't rotate automatically. Once you've proven a KMS key, it can't be changed to a different one. If you may ever need to move to a new key, choose a public key instead: each rotation there is a new key pair, and you keep every old private key.
Capture doesn't start until you've proven you hold the key and an Owner or Admin has confirmed it.
The quickest way, for a KMS key. In Settings, open Encryption key and choose Make a setup code. The dashboard shows a one-time code, valid for 15 minutes, and the command to run. Run records-custody create-key with your own AWS credentials. It shows your organization's name and asks you to confirm, then creates the key, adds Nota's policy statements, turns on automatic rotation, checks the key, registers it and proves it. If a step fails, it prints the key it created and how to continue. It never deletes a key. Then confirm the key in the dashboard (step 4 below).
Or step by step:
records-custody apply-policy can add them for you, from the statements file that Download statements saves: it shows the change and asks first, leaves your other statements alone, and turns on automatic rotation. The statements let Nota create data keys, encrypt a one-time challenge and read the key's health (below). They don't let Nota decrypt. For a public key, upload an RSA public key of 3072 bits or more. The dashboard refuses a private key.records-custody prove, then paste the result back into the dashboard. For a KMS key, prove first checks your key's policy and refuses if any statement could let someone in Nota's AWS account decrypt with the key, re-encrypt with it, grant access to it or change its policy.The policy check runs on your computer with your credentials. It protects you from a mistake in your policy, but Nota sees only the result of the proof, not your policy, so it isn't Nota verifying your policy. You can run the same check any time with records-custody check-policy.
For a KMS key, Nota reads the key's state, whether automatic rotation is on, and its grants: when you register it, when you prove it, and every six hours after that. These are read-only requests, and they appear in your AWS CloudTrail logs every six hours. Nota warns you when:
You accept the current warnings when you confirm the key. A new warning after that shows in Settings. A warning doesn't pause capture by itself. A disabled or deleted key still stops capture, as described under Pausing and resuming capture.
One problem can't be accepted: a grant on your key that would let someone in Nota's AWS account decrypt with it. Nota won't take the proof while one exists. If one appears later, revoke it at once. Nota shows a banner on every dashboard page until the grant is gone. Capture keeps running meanwhile. Nota's services can't use such a grant: their AWS permissions explicitly deny decrypting with any key outside Nota's account. That doesn't yet cover Nota's staff accounts, so the grant still has to go.
Nota can't see anything about a public key's private half, so a public key comes with standing warnings you accept when you confirm it: Nota can't see the key's state, rotation or deletion; you must keep every old private key, because records open only with the key that protects them; and losing a key makes its records unreadable for good.
For a public key, the private half lives in AWS KMS today. records-custody setup can create a suitable asymmetric key in your account and prints the public key and its fingerprint.
Two more places for the private half are coming, and aren't available yet:
You use records-custody, Nota's command-line tool, to prove, read and verify with your key. Only you can open your stored records, so you read them with your own key using records-custody. It signs in with a read token that you issue in Settings, under Read and verify.
Nota will publish the source for records-custody, and its signed releases, on GitHub at launch, so you can audit it and build it yourself.
records-custody read downloads your archive and decrypts it into a new, empty folder: events.jsonl and an attachments/ folder. If it can't open some segments, such as ones protected by a key you no longer hold, it reads the rest and lists what it couldn't open.records-custody verify compares the archive with Nota's ledger and signed record, and with a list of the public key fingerprints you've pinned. It can catch records that have been changed or that no longer fit the chain, a signed record issued for another customer or gone out of date, and a registered public key that isn't one of yours. That last check detects a swap. It doesn't prevent one. For each key that protects your records, verify also reports whether it still opens them, how many segments it protects and their dates, and fails if a key is no longer available.You can download whenever your records are available, including while capture is paused. Each download is recorded in your audit trail by count and kind, with no content, and your key system's own logs show each use of your key.
To set it up:
records-custody token save. It asks for the token without showing it as you type, or takes it from standard input when you pipe it in, and keeps it in a file only you can read. It refuses a folder other users can reach. read and verify use that file, or a different one named with --token-file.records-custody read --api API --customer ID --region REGION --key-id KEY --pinned PIN-FILE --out DIR and records-custody verify --api API --customer ID --region REGION --key-id KEY --pinned PIN-FILE. Settings also shows the pin file: a kms-key line with your key's ARN (or your public key's fingerprint) and a signing-key line with the fingerprint of Nota's signing key.A read token can read and verify your archive and nothing else. It can't issue, extend or revoke tokens. Admins and Owners see every token for the organization and can revoke any of them; anyone who issued a token can revoke their own. A token can't be renewed or edited. To replace one, sign in, issue a new token, run records-custody token save again, then revoke the old one. If a token may have leaked, revoke it first.
records-custody verify prints its full list of limits each time it runs. These are the main ones.
A read token can be saved on a machine that runs verify on a schedule. Give such a token a lifetime that fits and revoke it when the job ends.
records-custody turns it on when it sets up the key. AWS keeps the same key and every earlier version, so older records stay readable and nothing changes in Nota. A key with imported key material rotates only on demand, and you must keep every key material you import. A key in a custom key store can't rotate. After proof, you can't move to a different KMS key.If a key is compromised. Records already stored stay under the key that protects them, and you still need that key to read them. New records can go to a new key only in public key mode. Nota doesn't re-protect stored records under a new key. Nota can't open them to do it, and with a retention lock the original locked version stays until its term ends anyway, so re-protecting wouldn't remove the exposure.
Nota can't stop you from destroying your own key, because that is also how you make your records unreadable on purpose. These steps make an accident unlikely and give you time to notice one:
records-custody verify regularly. It fails if a key that protects your records no longer opens them.This applies to the KMS key mode. In public key mode, Nota never contacts your key system, so capture isn't affected when you turn it off.
Messages sent during a gap may not be captured. The messaging service may redeliver some that weren't acknowledged, but Nota can't promise that, so treat anything sent during a gap as possibly lost.
In Settings, turn on the retention add-on and choose a term from 1 to 30 years. Choose Backfill existing records to lock what's already archived too. Turning it off stops locking new records, and existing locks stay until their term ends.
Canceling stops capture. Without locked records, you have 30 days to export and can reactivate during that time. After a Nota employee approves disposal, your key is destroyed and your archive becomes permanently unreadable. Locked records, and the keys that open them, stay until the last term ends. If you hold your own key, disposal works differently; see Customer-held keys.