Security Statement

VitaMedas runs two services with two different security models. This Statement keeps them apart, because the difference matters.

• The Health records vault (on vitamedas.com and inside the app) is zero-knowledge. Files are encrypted on your device with a key only you hold. Our servers store ciphertext and cannot decrypt it.
• The Vita assistant is not zero-knowledge. An AI model cannot answer text it cannot read, so our app server can read your questions, Vita’s answers, Vita’s memory, profiles, medicines, period data and documents attached in chat. We protect that data with encryption in transit, access controls and the other measures below.

Both services run on servers operated by Hetzner Online GmbH in Helsinki, Finland (EU).

VitaMedas is designed against the following adversaries:

• External attackers attempting to read or modify user data via the public API, the web application, or the mobile apps.
• Compromised network paths (TLS-stripping proxies, malicious or coerced upstream networks, hostile Wi-Fi).
• Compromised infrastructure — including a scenario in which our host or a sub-processor is compromised. For the vault, root access to the server yields only ciphertext. For the Vita assistant, root access to the app server would expose app data; we reduce that risk with the access controls in Sections 7 and 17.
• Malicious insider — someone with production access. For the vault, they see ciphertext and pseudonymous metadata, never content. For the Vita assistant, production access could reach app data; access is limited to a few named people, and every time our admin panel opens a person’s health data, it is logged (who, whose, when).
• Legal-process adversary — a third party compelling VitaMedas to disclose user content. For the vault, we cannot disclose what we cannot decrypt: only ciphertext, account metadata and audit-log entries. Vita assistant data is readable, so it could be disclosed if a valid legal order requires it.
• Lost device on which a user has signed in. Mitigated by server-side session revocation, and on the web by the vault locking when you sign out or after 12 hours without activity.

We explicitly accept the following risks as out of scope of the VitaMedas threat model:

• Endpoint compromise. A fully compromised user device — including malicious browser extensions, hostile kernel-level malware, or a jailbroken iPhone — can capture the user’s passphrase at entry. We recommend a dedicated browser profile for medical records, and the iOS app checks for signs of jailbreak or a debugger, but endpoint integrity is ultimately the user’s responsibility.
• Lost vault key. Because vault keys are derived on your device from secrets we do not hold, a lost passphrase and lost recovery factors mean lost vault files. This is the price of zero-knowledge.
• Social engineering of the data subject. If a user is tricked into sharing records with a malicious party, we cannot un-share something that has been read.

Sections 3.1 to 3.5 describe the Health records vault only. Section 3.6 describes the Vita assistant.

Vault keys are generated on your device and never sent to VitaMedas in cleartext.

• In the iOS app, a vault device key may be kept in the iOS Keychain with kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, so you do not retype your passphrase on every launch. It stays on that device and is not synced to iCloud.
• On the web, while the vault is unlocked the keys are cached in this browser’s storage, so a refresh does not ask for your passphrase again. The cache is cleared when you lock the vault or sign out, after 12 hours without activity, and when the server ends your session.
• Recovery. You can add recovery factors (a recovery phrase, a passkey, or recovery shares given to people you trust). Each one wraps the same key; the server stores only the wrapped result and cannot use it.
• Server-held key for chat attachments. The key that encrypts documents attached in the Vita app is kept in the app server’s protected configuration, separate from the database, and is never logged.

• Sign-in. Sign-in uses Firebase Authentication (Apple, Google or email). On vitamedas.com you can also sign in with an emailed sign-in link or by scanning a code with the app. Our servers verify the sign-in and then issue their own session cookie.
• Session cookies. Sessions are HMAC-signed cookies, HttpOnly, Secure and SameSite=Lax: tai_session in the Vita app (14 days) and vita_session on vitamedas.com (90 days). A vitamedas.com session can be revoked on the server. The long web session does not expose vault content, which still needs your vault key.
• CSRF protection. A double-submit token (tai_csrf / vita_csrf) is issued with the session cookie. Requests that change data must echo it in a header.
• Sign-in links (magic links) are single-use. On vitamedas.com they expire after 15 minutes, and in the Vita app after 30 minutes. Password-reset links expire after 1 hour.
• Brute-force protection. Password sign-in in the Vita app is limited per account, and bursts of refused sign-ins from one address raise an alert. Refused sign-ins are recorded as security events (kept 30 days). Sign-in-link requests are rate-limited, and too many wrong codes disable a doctor link.
• Automated monitoring. Automated checks look at security events every few minutes (for example, many requests for records that are not the requester’s, or bursts of refused sign-ins) and alert our team.

• HTTPS everywhere. All traffic uses TLS. TLS from your device ends at Cloudflare’s network, which connects to our servers over HTTPS (TLS 1.2 or 1.3).
• HSTS on vitamedas.com with includeSubDomains; preload, so browsers refuse plain HTTP.
• Content Security Policy on vitamedas.com: scripts need a per-request nonce (strict-dynamic), and pages may connect only to our own origin. Inline styles are allowed. Two sandboxed paths that decode medical-image formats get their own narrower policy that allows the decoders to run; that permission never applies to the pages themselves.
• X-Frame-Options DENY; Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy set to same-origin; Referrer-Policy strict-origin-when-cross-origin; Permissions-Policy turns off the microphone and location, and allows the camera only on our own pages (so you can photograph a report).

VitaMedas runs on servers operated by Hetzner Online GmbH in Helsinki, Finland. Hetzner’s data centres are ISO 27001 certified and located within the European Economic Area.

• Network. Requests reach our services through Nginx as a reverse proxy, with rate limits. Application ports listen on localhost only.
• Process supervision via PM2 with automatic restart on crash.
• Databases. SQLite (better-sqlite3) in WAL mode. The vault database holds ciphertext and metadata. The Vita app database holds readable app data; it is not encrypted field by field and is protected by access controls on a single locked-down server. Our rule is that every read of health data in the app API is limited to the owner’s account in the database query itself.
• Secrets management via environment files under restrictive file permissions. Secrets can be rotated with an internal utility and are never logged.

• TypeScript strict mode across the web and vault backend.
• Private source code. Our source code is kept in private repositories; there is no public copy.
• App release checks. Before each app build is uploaded, automated checks scan the built app for keys, vendor addresses, demo logins and debug hooks, and fail the upload if any are found.
• Website release checks. A vitamedas.com release ships only committed code, refuses to overwrite newer live code, and runs an automated test of the record viewer before and after it goes live.

Every entry in the vault audit log is hashed and chained to the one before it, and signed with our server key. Once an hour, the new entries are combined into a single hash (a Merkle root), signed, stored, and submitted to the public Sigstore Rekor transparency log. Rekor is a public append-only log; the published hash reveals neither content nor identifiable metadata. If Rekor cannot be reached, the signed anchor is still kept on our server.

The property this provides is tamper-evidence: a later edit, deletion or insertion of vault audit entries by VitaMedas (deliberate or otherwise) breaks the chain of anchored hashes and can be detected by third parties without disclosing any private information. Customers under the Data Processing Agreement may request the Rekor entry indices for their tenant’s audit-log range and independently verify integrity.

Separately, our admin panel records every time a team member opens a person’s health data in the Vita app (who, whose, when, where).

• Vita app database: a full, compressed copy once a day, kept for 30 days. An extra copy made before a software change is removed within 35 days, so no backup is older than that.
• Vault server: any copy of the vault database and the encrypted vault files stays on the same host, contains vault ciphertext only, and is removed within 35 days.
• Location. Backups stay on the same host in Finland. Data never leaves the EU for backup.
• Recovery point. Because the Vita app database is backed up daily, a full restore of it could lose up to about 24 hours of changes.

VitaMedas acknowledges reported security incidents within twenty-four (24) hours. Automated checks (Section 5) alert our team to unusual activity as it happens.

• Notification of Personal Data Breaches is issued to affected Customer Controllers within seventy-two (72) hours of awareness, in the form required by Article 33(3) GDPR. Where we are the controller, we notify the competent supervisory authority within 72 hours and affected people without undue delay where Article 34 GDPR requires it. For Turkish data subjects, VitaMedas additionally cooperates with the Customer’s obligation under Article 12(5) KVKK.
• FTC Health Breach Notification Rule. VitaMedas is a vendor of personal health records within the meaning of 16 C.F.R. Part 318. We are not a HIPAA covered entity, and that is precisely why this Rule reaches us: it exists to cover the health records HIPAA does not. On discovering a breach of unsecured individually identifiable health information we will, without unreasonable delay and in no case later than 60 calendar days after discovery, notify each affected US individual and the Federal Trade Commission, and — where 500 or more residents of a State are affected — prominent media serving that State, with the FTC notified within 10 business days in that case. The notice will say what happened, what information was involved, which third parties acquired it, what we are doing, and what you can do. The Rule treats an unauthorised disclosure as a breach, not only a malicious intrusion, so a mistaken disclosure to a partner or an analytics tool would trigger it too. Data in the zero-knowledge vault is encrypted with keys we never hold and is therefore secured within the meaning of the Rule; the Vita assistant’s data is readable by our server, is not, and is the material risk.
• State breach-notification laws. Every US state has one, most define medical information as triggering data, and several set deadlines shorter than sixty days. We notify to the shortest applicable deadline across all affected jurisdictions rather than running fifty separate clocks, and we notify state Attorneys General where their law requires it.
• Status page — a public availability and incident-update page is planned. Until it launches, availability and incident notices are communicated by email to affected account holders.
• Security contact: security@vitamedas.com.

Good-faith security research on VitaMedas is welcome. Researchers are asked to:

1. report vulnerabilities to security@vitamedas.com;
2. provide reproduction steps and a reasonable time for VitaMedas to remediate before public disclosure (we aim for 90 days);
3. avoid degrading service availability or accessing data of any user other than test accounts that the researcher controls.

VitaMedas commits to not pursue legal action against researchers acting in good faith and within the bounds above, irrespective of any contrary provision of the Terms of Service. We do not yet operate a paid bug bounty.

Transparency requires that we name the things this Statement does not protect against:

• Vita assistant data is readable by us. It is not end-to-end encrypted. A compromise of the app server, or a valid legal order, could expose it. Only the vault has the zero-knowledge guarantee.
• Backups on the same host. Our backups stay on the same host in Finland. A total loss of that host could affect the live data and the backups at the same time.
• Lost vault passphrase. VitaMedas cannot recover your vault files if you lose your passphrase and every recovery factor. This is by design — any “recovery” mechanism we held would also be a mechanism by which a hostile party could compel us to recover your data. We will not build such a mechanism.
• Client-side compromise. A malicious browser extension, hostile operating-system root process, or compromised keyboard can intercept your passphrase before any of our cryptography runs. We recommend a dedicated browser profile (with extensions disabled) for sensitive medical sessions.
• Endpoint security is the user’s responsibility. We do not run an endpoint protection programme on user devices.
• Doctor link viewers, by their nature, see decrypted content in their browser; once a record has been viewed, it cannot be un-viewed.
• Quantum. The cryptographic primitives in use (XChaCha20-Poly1305, Argon2id, X25519, Ed25519) are not post-quantum. We track NIST’s PQC schedule and intend, as a roadmap goal, to migrate to a hybrid X25519 + ML-KEM construction for sharing once a stable, production-grade library implementation of the standard is available.

We state our compliance position honestly:

We do not claim certifications we do not have. When we obtain a certification, we will publish the certificate and the auditor report summary at this URL and in the audit-letter section of the DPA.

VitaMedas intends to commission an external penetration test by a recognised independent third party as the Service and its customer base mature, and to repeat it periodically thereafter. Anticipated scope includes the public web application, the mobile apps, the public API surface, and an authenticated grey-box review of the cryptographic implementation. Where a test has been performed, a redacted summary of findings and remediations is made available to Enterprise Customers under NDA on written request to security@vitamedas.com.

Before we use a sub-processor, we review its security and data-protection terms: a processing agreement with obligations equivalent to Article 28 where the vendor offers one, its certifications, its cross-border transfer safeguards, and its incident-notification commitments. Where a vendor offers no processing agreement, the sub-processor list says so and we limit what we send to it. VitaMedas may end any sub-processor relationship for material non-compliance. The current list of sub-processors is published at vitamedas.com/legal/subprocessors.

• Production access is limited to a few named people who need it, on a least-privilege basis, through SSH keys. Access is removed when someone no longer needs it.
• Having a team role grants administration, never reading. The app API has no admin route into another person’s health data. The admin panel is the only place a team member can open a person’s health data, and every such opening is logged.
• For the vault, production access does not allow anyone to decrypt files. For the Vita assistant, people with production access can technically reach app data; that is why we keep the group small and log admin-panel reads.

We will update this Security Statement to reflect new controls, improved primitives or operational changes. Material updates that decrease the overall level of protection are notified to Customers at least thirty (30) days before they take effect; we do not anticipate ever issuing such an update. Date and version of the current Statement appear at the head of this page; prior versions are archived and available on request.

Version 2.2 (12 October 2026) corrects earlier text. It did not lower any protection. The earlier text described the vault’s zero-knowledge design as if it covered all data; it now separates the vault from the Vita assistant. It also corrects the hosting location (Helsinki, Finland), the key-derivation parameters, the session lifetimes, the anchoring schedule and the backup description, and removes controls we could not show were in place.

Version 2.5 corrects the backup description again. The Vita app database is copied once a day and each copy is kept for 30 days; the earlier text said seven daily and four weekly copies. The earlier text also said the vault server was copied daily. It now says only what is kept: any copy of the vault server is removed within 35 days.