Product notes
Where personal information lives
This design began with an uncomfortable moment in everyday operations: investigating a failed login and seeing information you did not need to see.
Investigation puts identity on your screen
If you run an identity platform, a familiar request comes in: “One of our users can't sign in.” To find the cause, you enter the customer's environment and locate the account.
You need to know whether the account is locked, and when and where the last attempt failed. Which sign-in route did the user take? Is the passkey registration still usable?
None of that involves who the person is. Yet the moment you open the account, you see a name, an email address, a phone number and linked account names on the same screen. You needed the account's state; the person's identity came with it.
"Please don't look" is not a control
while it is rendered on the page.
The investigator has done nothing wrong. The customer asked for help, the procedure was followed, and the information still appeared. The system is built to show it.
Rely on policy and training alone, and protection rests on the investigator's memory and judgment. That is not enough to prevent an eventual incident. Authrim puts personal information in a separate database because we wanted to solve this problem in the design itself.
Usually, it all goes into one database
When you build an identity system, user data naturally ends up together: names and email addresses, app permissions, signed-in devices, passkey registrations and links to external identities.
All of it concerns the user. Putting it in one database is the straightforward approach, and it works. The difficulty comes later, when someone asks you to explain where personal data lives.
“Where is personal information stored?” “What would a breach expose?” “How do you handle a deletion request?” If everything is in the same place, the answer is always “the entire user table.” You cannot give a narrower account of the scope.
Two databases, drawn from the start
Identifying data sits in a physically separate database. Not retrofitted — the repository layer is split at the source.
With storage separated, the investigator can use the left-hand side for the opening case. It holds lock state, failed attempts and device information. Access to that side can be granted without opening the right-hand side. Nobody has to remember to look away.
The same structure makes audit questions easier to answer. You can point to where names and email addresses live and describe the scope of a deletion. We set out to solve an operational problem; the clearer explanation came with it.
This does not mean PII DB is the only personal data
This distinction matters. This split is not a legal boundary between personal and non-personal data.
Core DB holds IP addresses, device information, session history, authentication events, credential metadata and stable internal user IDs. Depending on context, those are personal data too. Individually they may not identify anyone; combined with other information, they can.
What Authrim actually separates is directly identifying data from operational identity data. The goal is that an investigation can run on the second without touching the first — not that the second needs no protection.
It would be inaccurate to say that personal data exists only in the PII DB. Names, email addresses and other directly identifying data are isolated there. Troubleshooting access can be granted without opening that store.
Deleting is the easy half
"Delete my account" is trivial to execute. The two requests that follow are not.
One is proving the deletion — when, by whom, and why, recoverable later. The other is blocking re-registration for a retention window, which is a common business rule.
Both requests ask you to recognise someone whose account you erased. But if you keep information that identifies them, you have not fully erased it.
The implementation states its own reasoning: store no PII, keep only the fingerprint needed to prevent duplicates, expire after the retention window, and record who deleted, when, and why.
What "not recoverable" depends on
One note for engineers. Email addresses are low-entropy. Fingerprint them with a plain hash and a dictionary attack recovers the original. "Not recoverable" is not unconditional.
Authrim uses an HMAC-SHA256 blind index with a secret key, carrying a key-generation number so keys can be rotated. Without the key, brute-forcing the fingerprint is not available.
Which means key isolation is the precondition for the guarantee. Store the key beside the fingerprints and the guarantee is gone. Do not drop that condition when describing this externally.
Give an investigation only what it needs
Return to the failed-login report. The investigator needs to find where authentication stopped. They usually do not need to open a name or phone number.
Authrim separates directly identifying information so that troubleshooting access can be granted without access to that store. When an investigation does need personal information, someone with the appropriate additional permissions handles it.
Encryption and access control protect the data; audit logs record its use. Alongside those measures, an investigator should be able to finish routine work without opening personal information they do not need. Separating storage makes that the starting point for everyday operations.
Implementation. Complete — storage split and access boundary both in effect
Validation. Covered by automated tests in this repository
Operational maturity. Hardening in progress. Authrim is pre-1.0.
This design makes deletion workflows easier to run. It is not itself a statement of legal compliance. Actual conformance depends on your procedures and contracts. Keep that distinction in external material.