KeyvaciLegal · Privacy Policy
Keyvaci Privacy Policy
This policy explains what personal data Keyvaci handles, why, and what rights individuals have. It covers the Keyvaci service operated by XNOR Group Pte. Ltd. ("we", "us").
The short version
We cannot read what you store in Keyvaci. Vault contents are encrypted in your browser with keys we never receive. What we do hold is the operational data needed to run the service: who is in an organisation, which vaults exist, who has access to them, and a record of security-relevant actions.
We do not sell personal data. We do not share it for advertising. We run no third-party analytics, advertising trackers or session-recording tools in the application. The marketing website uses analytics only if you allow it, and never for advertising; section 12 sets out exactly what that involves.
1. Controller and processor roles
Keyvaci is sold to organisations. For the data of an organisation's members, the customer organisation is the controller and we act as its processor. Our obligations in that role are set out in the Data Processing Addendum.
We act as a controller in our own right for a narrow set of data: billing records, correspondence with us, and security logs we keep to protect the service.
If you are a member of an organisation using Keyvaci and want to exercise rights over your data, contact your organisation first. We will assist them, but we will not act on their data without their instruction unless the law requires us to.
2. What we hold
2.1 Data we can read
| Category | Fields | Why |
|---|---|---|
| Member identity | Microsoft Entra object identifier, work email address, display name, role in the organisation, account status | To identify members, address invitations, and apply access control |
| Organisation | Organisation identifier, Entra directory identifier, subscription status, trial end date, seat count, organisation public keys, password age setting | To run the tenant and apply entitlements |
| Invitations | Invited email address, who invited, when | To let a new member join, and to show administrators what is outstanding |
| Access structure | Which vaults exist, who holds access to each, at what role, who granted it, key version | To enforce authorisation. Vault names are encrypted and unreadable to us |
| Audit records | Event type, acting member, timestamp, and the affected object; for example vault opened, entry revealed, access granted or revoked, recovery used, terms accepted | Security, incident investigation, and the customer's own compliance obligations |
| Sign-in credentials (email sign-in only) |
Whether and when the address was confirmed; a counter that is raised whenever every existing session must be ended; the digest of any one-time link that is still outstanding | To let somebody prove who they are by opening a link we send to their address. There is no sign-in password: we do not ask for one and hold none, so there is no credential here to be stolen from us. A link is stored only as a digest, so a copy of our database yields no working link. Members who sign in through Microsoft Entra ID have none of this |
| Second factor (email sign-in only, if enabled) |
The shared secret an authenticator application uses to produce codes, encrypted under our key management service and not readable from the stored record; the last code period accepted, so a code cannot be used twice; and a SHA-256 digest of each unused recovery code | To check a one-time code. The secret is encrypted separately from the rest of the record because anyone holding it could generate valid codes indefinitely, which is exactly what the second factor exists to prevent |
| One-time links | A SHA-256 digest of each address-confirmation, password-reset and invitation link, with the address it was issued for and its expiry. The link itself is never stored | So a link can be used exactly once and then stops working. Storing only the digest means a copy of our database yields no usable links |
| Key material we cannot use | Public keys; the member's private keys in encrypted form; the key-derivation parameters and salt | To deliver a member's own encrypted keys back to their browser. We hold no means to decrypt them |
| Billing | Stripe customer and subscription identifiers, plan, billing cycle, seat quantity, invoice status and dates | To charge correctly and show payment history. Card details go to Stripe and never reach us |
| Operational logs | Request identifiers, error types, IP address and user agent at the edge, rate-limit counters, the names of token claims present in a failed sign-in | Availability, abuse prevention and diagnosis. Log content deliberately excludes request bodies and token claim values |
| Terms acceptance | Which version of these documents was accepted, by which member, and when | To evidence agreement, and to know when re-acceptance is needed |
2.2 Data we hold but cannot read
The contents of every vault entry, and the name of every vault, are stored only as ciphertext with its authentication data. We have no key, and no procedure, that would let us or any of our staff read them. This is not a policy commitment that could be reversed by a change of mind; it is a property of how the system is built.
2.3 What we never receive
- Master Passwords. They never leave the browser, not even in hashed form.
- The Organisation Recovery Key and Organisation Signing Key.
- Payment card numbers.
- Directory passwords, where an organisation signs in through Microsoft Entra ID. That authentication happens at Microsoft, not with us.
One important distinction. Where an organisation signs in with an email address instead, there is still no sign-in password. Signing in means opening a single-use link we send to the address, which proves the person holds it. We store only a digest of that link, never the link itself, and it expires five minutes after it is sent. The Master Password is a different secret altogether: it decrypts the data, never reaches us in any form, and cannot be reset by us or by any link we send.
3. Where the data comes from
- From the member's Entra account, through the sign-in token: object identifier, tenant identifier, display name, work email. We never receive the directory password.
- From the person directly, where email sign-in is used: the address, a display name, and a password which we hash immediately and never store as typed.
- From administrators, when they invite members or change settings.
- From use of the service, in the form of audit records and operational logs.
- From Stripe, in the form of subscription and invoice status.
4. Why we process it, and on what legal basis
| Purpose | Basis under GDPR | Basis under PDPA / Decree 13 |
|---|---|---|
| Providing the service under our contract with the customer | Performance of a contract (Art. 6(1)(b)), or legitimate interests of the customer where the individual is not the contracting party | Necessary for a contract with the individual's organisation; notified purpose |
| Security, abuse prevention, audit trail | Legitimate interests (Art. 6(1)(f)): running a credential vault securely | Legitimate purpose notified at collection; security is an express obligation |
| Billing and tax records | Legal obligation (Art. 6(1)(c)) and contract | Legal obligation under accounting and tax rules |
| Service and security notices | Legitimate interests, and contract | Notified purpose. These are not marketing messages |
We do not use personal data for automated decision-making producing legal effects, and we do not profile individuals.
5. Marketing
We send administrators messages necessary to run the service: billing notices, security advisories, and material changes to these documents. These are not marketing and cannot be opted out of while the subscription is active. Any genuine marketing email will be sent only with consent and will carry an unsubscribe link.
6. Who else is involved
We use a small number of processors. Each is bound by contract to process data only on our instructions and to protect it. The current list:
| Provider | Role | Data | Location |
|---|---|---|---|
| Amazon Web Services | Hosting, database, key management, logging, and sending our email | All operational data and all ciphertext. Amazon SES additionally handles the recipient address and name on address-confirmation, password-reset and invitation messages | Singapore (ap-southeast-1). Edge delivery and certificate services also use AWS facilities in the United States and globally distributed edge locations |
| Stripe | Payment processing | Billing contact email, subscription and invoice data, card details collected directly by Stripe | United States and Ireland |
| Microsoft | Identity provider | Authentication happens in the customer's own Entra directory. Microsoft is the customer's provider, not our sub-processor, but sign-in necessarily involves it | As determined by the customer's own Microsoft tenant |
We will give notice before adding a sub-processor, as set out in the Data Processing Addendum, so that customers may object.
We disclose data outside this list only where required by a binding legal demand (see section 11), or to professional advisers under a duty of confidence, or to a successor in a merger or sale of the business, in which case this policy continues to apply until replaced with notice.
7. International transfers
Data is primarily held in Singapore. Where personal data of individuals in the European Economic Area, the United Kingdom or Switzerland is transferred outside those areas, we rely on the European Commission's Standard Contractual Clauses, incorporated by the Data Processing Addendum, together with a transfer risk assessment.
For transfers out of Singapore, we meet the transfer limitation obligation under the PDPA by binding recipients to a comparable standard of protection by contract. For personal data of individuals in Vietnam, we maintain the records required by Decree 13/2023/ND-CP and will co-operate with the customer's own impact assessment dossier.
8. How long we keep it
| Data | Retention |
|---|---|
| Vault ciphertext and access structure | Until deleted by the customer, or 30 days after the organisation is terminated |
| Member profiles | Life of the membership, then deleted with the organisation |
| Email sign-in accounts | Life of the account. The password hash is replaced whenever the password changes and is never retained in an older form |
| One-time links | Sign-in link 5 minutes, address confirmation 24 hours, invitation 24 hours. Deleted the moment the link is used, whichever comes first |
| Audit records | Retained for the life of the organisation and not deletable by customers, because an audit trail that a suspect can erase is not an audit trail. Deleted with the organisation, subject to any legal hold |
| Public keys of former members | When a member leaves, their two public keys and the organisation's signature over them are kept for the life of the organisation, and nothing else about them is. This is what lets the entries they wrote still be verified: without it, one person leaving would make every entry they ever created read as unsigned to their colleagues. No name and no address is kept with them. Deleted with the organisation |
| Backups | Point-in-time recovery window of 35 days. Deleted data disappears from backups as that window rolls forward |
| Billing and tax records | Five years, as required by Singapore accounting and tax law |
| Operational logs | 30 days for application logs, 7 days for the health endpoint |
| Rate-limit counters | Automatically expired within two counting windows, typically under an hour |
| Terms acceptance records | Life of the organisation plus six years, as evidence of contract |
9. Security
Measures in place, described plainly rather than as a list of adjectives:
- End-to-end encryption of vault contents, with keys derived in the browser using Argon2id and never transmitted.
- Encryption in transit (TLS 1.2 or above) and at rest, with a separate customer-managed key per environment.
- Tenant isolation enforced in a single code path that constructs every database key, with automated cross-tenant tests that block deployment on failure.
- An append-only audit trail, enforced by infrastructure permissions rather than by application code, so that no application bug can rewrite history.
- A strict content security policy that forbids inline scripts and allows third-party script from exactly one origin, Cloudflare Turnstile on the contact page, to check that the form is being filled in by a person. No other origin may run script here, and that is the control that protects in-browser key material.
- Per-user rate limits on revealing and on retrieving encrypted vault contents, and a web application firewall at the edge.
- No sign-in password at all where email sign-in is used, so there is no credential of that kind for us to hold or to lose. A sign-in link is 32 random bytes, stored only as a SHA-256 digest, usable once, and dead five minutes after it is sent. Asking for one is rate limited both by address and by network address, and answers identically whether or not an address has an account.
- An optional second factor for email sign-in, using time-based one-time codes from any authenticator application. The secret is encrypted under our key management service, each code period is accepted at most once, and attempts are rate limited more tightly than passwords because the code space is smaller.
- Session tokens signed with an Ed25519 key that only the sign-in component can read. The component every request passes through holds the public half only, so compromising it cannot produce a token for anybody.
- Least-privilege access for our staff. No member of staff can read vault contents; that is a property of the design, not a permission setting.
No system is perfectly secure. Section 14 of the Terms of Service states what we do and do not warrant, and how to report a vulnerability.
10. Rights of individuals
Depending on where you are, you may have rights to access, correct, delete, restrict or object to processing, to portability, and to withdraw consent where consent is the basis.
How to exercise them. If you are a member of a customer organisation, contact that organisation. They control your data and can act directly in the service for most requests. If you contact us instead, we will refer you to them and assist them in responding.
An honest limit. We can act on the operational data listed in section 2.1. We cannot act on the contents of vault entries, because we cannot read them or tell whose personal data they might contain. A request to delete "my data inside a vault entry" must be directed to the organisation, which can decrypt and edit it.
Complaints. You may complain to your supervisory authority: the Personal Data Protection Commission in Singapore, your national data protection authority in the EEA or the UK, the Ministry of Public Security in Vietnam, or the California Privacy Protection Agency. We would appreciate the chance to resolve the matter first.
10.1 California
In the twelve months preceding the date of this policy we have not sold or shared personal information as those terms are defined by the CCPA, and we do not do so. We do not process personal information for cross-context behavioural advertising, and we do not knowingly collect data from children. California residents may exercise rights of access, deletion, correction and non-discrimination through the routes in section 10.
11. Requests from authorities
If we receive a binding legal demand for data, we will, unless legally prohibited, notify the affected customer before responding so that they may seek protective relief, and we will produce only what the demand requires and what we actually hold.
What we actually hold is operational data and ciphertext. We cannot produce readable vault contents. This is a factual limit, not a policy position.
12. Cookies and local storage
The application at console.keyvaci.com sets no advertising or analytics cookies. It stores a small amount of data in the browser strictly to function:
- the chosen interface language;
- the authentication session: for Microsoft sign-in, held by Microsoft's library in session storage; for email sign-in, a token we issued, which expires an hour after it is granted and cannot be renewed beyond twelve hours from the original sign-in. Both are cleared when the browser tab closes;
- during an account recovery, a temporary key generated in the browser, which carries an expiry and is erased when the recovery finishes or lapses.
The marketing website at keyvaci.com can use Google Analytics to count page views, and only if you allow it. Nothing is loaded and no analytics cookie is set until you choose to allow it in the banner. Declining, or sending a Do Not Track or Global Privacy Control signal, means the analytics script is never requested at all.
If you do allow it, Google Analytics sets its own first-party cookies to recognise a returning browser, and receives the page you viewed, the page that referred you, an approximate location derived from your IP address, and basic device and browser information. We use this to see which pages are read and where an explanation fails. We do not use it for advertising: Google's advertising features and ad personalisation are switched off, and we neither sell nor share this data. Google processes it on our behalf, under its own terms.
You can change your answer at any time from the Analytics choice control in the footer of any page on the website. Declining there also deletes the analytics cookies already set. The choice is remembered in your browser, so it applies per browser and per device.
Decryption keys are held in memory only, are never written to storage, and are erased on sign-out, after fifteen minutes of inactivity, or five minutes after the tab is hidden.
13. Children
Keyvaci is a business product and is not directed at children. We do not knowingly collect personal data from anyone under 16.
14. Changes to this policy
We will update this policy as the service changes. The version identifier at the top changes with it. For changes that materially affect individuals, we will notify administrators at least 30 days in advance and, where the change affects the basis on which the service is provided, ask an administrator to accept the updated documents in the application.
15. Contact
XNOR Group Pte. Ltd., Singapore.
Privacy enquiries, data protection requests and security reports:
keyvaci@xnorgroup.com