How are PINs stored and protected?

Each User who chooses PIN sets their own six-digit PIN directly on the Device. No administrator, supervisor, or SOBEREYE personnel sets, issues, or can view a PIN at any point, so there is no administrator-visible credential and no PIN distribution channel to secure.

The PIN is stored only as a derived value and is never stored, logged, cached, or transmitted in clear text:

• Derivation function: PBKDF2-HMAC-SHA256.
• Salt: a unique, cryptographically random salt per User, generated when the PIN is created.
• Work factor: iteration count tuned to approximately 100 ms on the oldest supported iPhone model.
• Storage on the Device: iOS Keychain, with the accessibility class kSecAttrAccessibleWhenUnlocked, so the derivations are not readable while the Device is locked.
• Verification: performed locally on the Device.

Verification on the Device is what allows PIN mode to work without connectivity. Each Device therefore holds the derivation and salt for every User in its synchronized user list; these reach other Devices through the same encrypted synchronization as the user list.

The work factor and per-User salt matter because a six-digit PIN has at most one million possible values. A fast, unsalted hash over that space could be exhausted in well under a second, and without per-User salts a single precomputed table could recover every PIN on a Device at once. Because verification happens once per assessment, a 100 ms work factor has no perceptible effect on the User.

The Device rejects a PIN made of the same digit repeated, such as 111111, or of sequential digits, ascending or descending, such as 123456 or 654321. No other composition rule applies.

PIN values do not appear in crash reports, diagnostic bundles, analytics events, or debug logging in any shipped build.