Is it safe to track your cycle in an app

The short answer

It depends on one thing — where the key is kept. If an app encrypts your entries with a key it holds itself, "encrypted" means only "encrypted against an outsider", not against the app. If the key stays on your phone, nobody can read the entries — including the people who built the app.

Those are two different things, and the word "encryption" hides the difference between them. What follows is how to see that difference for yourself, in any app, not only in ours.

Why "we encrypt your data" is not an answer

Almost every app encrypts something today, and technically none of them is lying. But one word covers three different things, and only the third guarantees anything.

• Transport encryption. Data is protected while it travels from your phone to the server. That is HTTPS, and every website has it, including a shoe shop. On the server the data is in the clear again.
• Encryption at rest. The disk or the database is encrypted, but the key belongs to whoever owns the server. This protects you against somebody carrying a disk out of a data centre. It protects you against the app's owner not at all.
• End-to-end encryption. Data is encrypted on your device with a key the app does not have. Ciphertext is what reaches the server, and the server's owner cannot open it even when they very much want to.

The first two are technical hygiene. The third is a property that a promise cannot revoke.

Three things that can actually happen

Cycle entries are health data. The risk here is not abstract, and it comes in three shapes.

• Access from the inside. If the key sits with the app, anyone with access to the database can technically read the entries. "We don't read them" is a promise, not a mechanism.
• A breach. A database that can be read from the inside can also be read by whoever got in without permission. The number of health-data leaks each year is not a hypothesis.
• A change of owner or of rules. A policy can be rewritten at any time: apps get sold, companies get bought, jurisdictions change. A mechanism cannot be rewritten — if the key does not exist, it still does not exist after the sale.

The third point is the most important and the least obvious. A privacy policy is an intention held today. Architecture is what will still be true tomorrow.

The question worth asking

Not "do you encrypt data" — everyone answers yes to that. There is one question: where is the key kept?

And two follow-ups:

• What exactly is encrypted — everything, or only part of it?
• What is visible on the server in the clear?

If there is no answer to the second, that is an answer already. An app that understands its own architecture can list the fields. An app that would rather not usually has something to hide — not from an attacker, but from you.

How Kvit does it

On the phone. The local database is encrypted in full. A 256-bit key is held in the system's secure storage — Keychain on iOS, Keystore on Android — and never leaves the device. It is the same store the operating system uses for passwords and for other apps' keys — the most protected place it offers an app at all.

In the cloud. The cloud copy is optional: the app works completely without it. If you turn it on, an entry is encrypted on the phone itself (AES-256-GCM) and only then uploaded. What reaches the server is a row shaped like "entry id, your id, ciphertext, time of change".

Why we cannot read your entries. Not because we promise not to, but because we do not have the key. That is the difference between "will not" and "cannot", and it is the only one that matters.

What is nevertheless visible on the server

This is the most important part, and the part usually left out. Visible in the clear:

• the time each entry was last changed;
• how many of them there are;
• whether you have turned on PIN or biometric entry.

Plus one more thing that has to be named: the presence of a file in the journal photo storage reveals the fact that you keep a pregnancy journal. Its contents stay ciphertext.

So the server sees that you are recording something, and when. It does not see what. We say this out loud, because an app claiming that nothing at all is visible on its server either does not understand its own architecture or is describing it inaccurately.

Section 3.2 of the privacy policy describes what sits on the server: an opaque blob in which neither the contents nor even the field names are visible. The metadata above is what surrounds that blob, and we name it here because a policy that stops at "we cannot read it" leaves out the more interesting half.

Who the data goes to

Kvit has no servers of its own, so the providers are named — all five: Supabase (database, storage and authentication; EU, Ireland region), Qonversion (subscription status, no health data), Apple and Google (payment, subscription management and sign-in), Google (Firebase) (technical installation identifiers and notification delivery, when notifications are on) and Cloudflare (hosting for the pages on kvitcare.com — it sees your IP address when you open this site, and nothing from the app).

Naming them is a mechanism too, not a courtesy: once a provider is named, we lose the ability to quietly add another. Who sees exactly what, and how long it lives, is worked through line by line in Who can see your cycle entries.

What this approach costs

There is a price here, and it is better known in advance.

If you have set up account recovery, a recovery key is additionally placed on the server, inside an "envelope" encrypted with your recovery passphrase (or a one-time recovery code, if you generated one). Without them the envelope does not open, and we have neither. The encryption key itself still stays on the device: only the envelope reaches the server, and we cannot open it.

You cannot have both properties at once. Either the app can restore your access — in which case it can read your data. Or it can do neither. We chose the second, and we say so before you lose anything, rather than after.

There is one practical conclusion: keep the recovery phrase where you keep important things, not in a note on the same phone.

What happens if you delete your account

Another question worth asking any app in advance, because the answer only ever gets tested once.

In Kvit, deleting the account erases the cloud copy. A deleted entry disappears from the app immediately and is permanently erased from the server within 90 days at the latest — that window exists so the deletion reaches your other devices, not "just in case". You can delete the account without installing the app: there is a page for that.

A checklist for any app

Five questions whose answers should be in a document, not in a store listing:

1. 1.Where is the encryption key stored?
2. 2.What exactly is encrypted, and what is not?
3. 3.What is visible on the server in the clear?
4. 4.Who else receives the data — and are they named individually?
5. 5.What happens to the data if the account is deleted?

A missing answer to any of them is also an answer. And one more check that takes a minute: open the app's privacy policy and search for "advertising partners" or "affiliates". If the list is not named, the list is open-ended.

What Kvit does not have

There are no advertising libraries in the app, we collect no advertising identifiers, and the app runs no behavioural analytics. Data is not sold and not passed to data brokers, and there is no cross-app or cross-site tracking.

One more detail worth knowing: a cycle forecast is information for you, not a decision about you. Kvit makes no automated decisions with legal effect concerning you, and the policy says so directly.

What this does not mean

Finally, the limit — because that has to be named too. End-to-end encryption protects data on the server. It does not protect you from someone holding your unlocked phone, and it does not make the app a medical device.

Kvit is a wellness app. It does not diagnose, it does not replace a clinician, and it is not a contraceptive. On how it calculates and where the limits of its forecast are, see How ovulation is actually calculated.