02
The station is a display, not a credential store
For phone sign-in, the workstation is never issued a SenseCrypt credential. It has no enrollment, holds no key, and performs no face check. It draws a sign-in page carrying a code and keeps a connection open until something tells it whose session to start.
Trust is anchored instead in hardware with exactly one owner, the worker's own enrolled phone. Scanning, the liveness test, the one-to-one comparison and the signature all take place there. Only once that sequence completes is the terminal released into a session, and the session carries a name.
Scan, look, in
The code is scanned with the companion app and the face check finishes on the worker's own handset. The station receives no password or one-time code, and nobody has to say anything aloud on a floor where sound carries.
Use a supported browser at each station
There is no agent to install, no key to provision and no enrollment to perform on the hardware. Any terminal that can render a page can start a ceremony.
A stolen terminal holds no enrollment or sign-in key
In the phone methods, the terminal stores no enrollment material or enrolled-phone authentication key. Browser sessions and application data remain subject to your workstation policy, including ending sessions between users.
Permissions travel with the worker
Roles resolve centrally and ride in the token your application reads, so somebody who moves between three terminals in an hour has the same access at each of them and no local configuration to maintain.
03
Where a webcam station fits
Some floors do not permit personal phones, and some sites cannot issue a device to every worker. There is an enterprise webcam method for exactly that situation, and its scope should be stated plainly rather than discovered during a pilot: it is a deviceless mode available to enterprise customers, not as a self-serve option, and it must run on secure terminals: part of the assurance comes from the managed workstation and the network it sits on, and an unsecured terminal exposes webcam capture to injection attacks such as virtual-camera or video-stream injection. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
Capture in that method happens at the workstation camera rather than on a phone the worker carries, which is a materially different posture from the mobile ceremony and is priced, scoped and deployed accordingly. If that is the shape of your floor, contact sales@seventhsense.ai and the conversation starts with the network and the workstation build.
The two phone methods keep the check on the phone
With Simple QR and with passkeys, liveness and the one-to-one match run inside the companion app on the worker's own enrolled phone, and the station learns only that the ceremony passed.
The webcam method uses enterprise-side capture
The account still belongs to one worker and the record still names that worker. What changes is where the capture happens, which is why the method is scoped to enterprise deployments on secure terminals.
04
What the identity records show
The point of all this is that the log finally names people. It is worth being exact about what that log is, because audit language gets stretched in this market and a security reviewer will notice.
Two records exist here, and they are not the same kind of record. Every authentication appends to a person-level stream that is read only and exports as CSV: the worker, the moment, and the device that answered. The hash-chained, tamper-evident log is the console one, and it covers configuration changes made by administrators. There is no customer-side verification of that chain, so the honest answer to an auditor is that we run it, not that you can check it yourself.
Every session carries a name
Whoever completed the ceremony owns the session that follows it. An investigation needs that mapping and nothing less, and it is precisely what a shared account is structurally unable to supply.
Two logs, two jobs
One answers who was standing at the terminal. The other answers who changed the settings behind it. Naming them separately is worth doing in a questionnaire, because they carry different guarantees.
Your application logs its own decisions
Because permissions are enforced inside your application, the record of what a worker then did with them belongs to your application rather than to the identity provider.
05
Deployment requirements for the workforce
One assumption carries the whole design, and it is the first thing to test rather than the last: during the shift, every worker has to hold a device capable of running the companion app, or the site has to qualify for the enterprise webcam method on secure terminals.
Where that holds, the handover ends up quicker than typing a password ever was, and accountability stops being the thing traded away to buy the speed. Where it does not, the device question has to be settled first, because no amount of configuration substitutes for a trust anchor that is not there.
06
Frequently asked questions
What does the shared workstation actually hold?
For phone sign-in, no enrollment material or enrolled-phone authentication key. It renders a sign-in page with a code and waits for the worker's own phone to complete the ceremony. Browser sessions and application data on it remain subject to your workstation policy.
Does each worker get their own audit record?
Yes. Every sign-in resolves to one enrolled worker and appends to a person-level record that exports as CSV. It captures authentication events. What that worker then does inside your application is recorded by your application, because that is where the permissions are enforced.
How fast is a handover?
Scan, glance, done. No password or one-time code is typed at the station, which was both the part that cost the time and the reason the shared password appeared in the first place.
Can we run this without personal phones?
Yes, with Simple Webcam, a deviceless method for enterprise customers in which capture happens at the workstation camera rather than on a phone. It must run on secure terminals, because unsecured terminals expose webcam capture to injection attacks. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor. It is not self-serve: contact sales@seventhsense.ai to discuss whether your environment qualifies.
Does a shared station sign-in count as phishing-resistant?
The terminal holds no password; the sign-in flow asks only for an email address. Where a requirement is written with the words phishing-resistant, enable the passkey path, which carries FIDO2/WebAuthn origin binding.
Does the station have to be a managed device?
For the QR flow, no. The ceremony happens on the worker's phone and the station is a display. For the enterprise webcam method the workstation and the network are part of the assurance, which is why that method is scoped to enterprise deployments and must run on secure terminals: an unsecured terminal exposes webcam capture to injection attacks.