Zero PII at the Reader: Why the Thin Reader Architecture Matters
Access control readers are physically exposed. They’re mounted on door frames, elevator lobbies, parking garage walls, and building exteriors. Anyone with a screwdriver and five minutes can remove a reader from a wall. If that reader contains personally identifiable information — employee names, biometric templates, credential data — its removal is a data breach.
Traditional readers don’t store PII because they don’t process identity — they read a badge number and send it to the panel. But identity-based access control introduces identity verification at the reader edge. The reader reads a digital ID, verifies it, and transmits the result. The question is: what does the reader retain after the verification?
The thin reader principle
In KeyShare’s Controller Derivation architecture, the reader is a verifier, not a data store.
The Reader Library firmware handles the ISO 18013-5 NFC protocol: session establishment, selective disclosure request, and cryptographic signature verification. During this process, the reader holds identity attributes (name, date of birth, document number) in volatile memory (RAM) for the duration of the NFC session — typically 1–3 seconds.
After the verification completes, the Reader Library transmits the result to the Panel Application via OSDP v2.2 (AES-128 encrypted) and clears the identity data from RAM. The reader’s persistent storage (flash) never receives identity data. There is no configuration option to enable storage. The architecture makes PII retention at the reader impossible, not just policy-prohibited.
If an attacker removes the reader from the wall and extracts the flash contents, they find: Reader Library firmware, OSDP configuration, and LED/audio feedback patterns. No identity data. No biometric templates. No credential history. No PII.
Why this matters for compliance
Privacy regulators increasingly scrutinize where PII is processed and stored. A reader that stores identity data — even temporarily on flash — creates a data processing point that requires documentation, access controls, encryption-at-rest, and breach notification procedures.
A reader that processes identity data in RAM and discards it in under 3 seconds has a different compliance profile. The data is transient. It exists only during the verification computation and is freed immediately after. There is no “data at rest” to encrypt, no stored dataset to breach, and no retention schedule to manage.
For CISOs conducting privacy impact assessments on identity-based access deployments, the “zero PII at the reader” property dramatically simplifies the assessment. The sensitive data processing happens in a well-defined boundary (the reader’s RAM, for a well-defined duration (the NFC session), with a well-defined outcome (transmitted to the panel via encrypted OSDP, then cleared).
The panel is the right boundary
The Panel Application on the Mercury controller sits in a physically secured IDF closet — locked, alarmed, access-logged. It derives a site-specific UUID from the verified identity attributes and validates the UUID against the credential manifest. The identity attributes are processed in transient memory on the panel as well — discarded immediately after UUID derivation.
The credential manifest (cached on the panel) contains UUIDs, not identity data. UUIDs are site-specific — they can’t be reversed to recover the original identity attributes and can’t be correlated across sites.
The architecture ensures that identity data never persists anywhere in the access control system. It enters the reader transiently, transits to the panel transiently, and is gone — replaced by a non-reversible, site-specific UUID.
