Stronger sign-in: trusted passkeys and blocked replays
Essence changed its sign-in code to require a PIN or biometric for every passkey, judge security keys against FIDO's published metadata and refuse replayed tokens.
When someone signs in to a service your organisation relies on, you want to know how much that sign-in is worth. Was it the person, or only their device? Was the key a certified piece of hardware, or a passkey that syncs between phones through a cloud account? Both kinds of passkey are useful. They are not the same strength.
In our October release, Essence changed its sign-in code so that the answer reflects the authenticator a person actually used, rather than assuming the best.
The person confirms it is them
A passkey proves that someone holds a device. It does not, on its own, prove that the person holding it is the owner. That is what user verification adds: the device asks for a PIN, a fingerprint or a face before it will sign. The check happens on the person's own device.
Essence's sign-in code requires that verification for every passkey, at registration and at each sign-in. Without it, both fail. The flag that says verification happened is read from the data the device signed, so it cannot be added afterwards without breaking the signature. Any request to make verification optional is ignored.
Knowing which key is signing in
When a security key registers, it can present an attestation statement: a signed declaration of its make and model. Essence verifies these statements for the packed, TPM, Apple and Android key formats, and checks the result against the FIDO Alliance's Metadata Service, the published register of authenticators and their certification. The certification level is recorded with the passkey.
Three rules follow:
- A passkey with no attestation is still accepted, as a syncable passkey at its own level. Nobody is locked out for using the passkey their phone offers.
- Only keys whose certification includes evaluation by a FIDO-accredited laboratory count as certified hardware. A passkey that can be backed up and synced never counts, whatever model it claims to be.
- If the register lists an authenticator as revoked or compromised, registration is refused.
For an organisation, a sign-in can then carry an honest answer to "what kind of key was this?", and sensitive actions can ask for the stronger kind.
Trust that can be withdrawn
Certification is not permanent. A model judged sound when it was registered can later be found to have a flaw.
If a revocation or compromise is published for an authenticator after registration, its passkey stops counting as certified hardware. When a sensitive action asks for a fresh passkey check, that check claims hardware-key strength only if the key counts as certified at that moment, not merely when it was first registered. The person's list of passkeys shows when a key's certification has been withdrawn.
Codes and tokens that work once
Two kinds of replay protection are built into the sign-in service.
Refresh tokens. A session renews itself with a refresh token, and each renewal issues a new one. If a token that has already been replaced is presented again, which suggests it was copied, the session is suspended so the copied token stops working, and the person is told.
One-time codes from an authenticator app. A code that has been accepted cannot be accepted again within its window, five wrong codes end the challenge, and the codes are stored hashed rather than as readable values.
Both follow one principle: a credential that has done its job once should not be able to do it again.
What this means for your organisation
For the people signing in, little changes on screen: the same passkey, confirmed with a PIN or fingerprint each time. For your organisation, the strength a sign-in claims rests on the authenticator actually used, judged against published metadata at the moment it matters. If you are assessing how Essence handles sign-in, we would be glad to take you through it.
Published 5 November 2026