01
Convincing synthetic faces are easier to create
The case reported in February 2024 at the engineering firm Arup is the one every board has now heard about: a finance employee released roughly 25 million US dollars in transfers after joining a video call whose other participants were all deepfakes of colleagues. That was a conference call and not an authentication ceremony, which is precisely why it is useful evidence. It shows that a synthetic face clears human review without difficulty.
Faces were never secrets in any case. They are on the badge, the conference program, the company page and every social feed, so a system that treats the face as confidential was mistaken from the start. Recognition is the easy half of this problem.
The hard half is deciding what the camera is actually looking at, and there are two very different ways for an attacker to get that wrong answer accepted.
- A printed photograph held up to the lens
- A recorded or generated video played back on a screen
- A paper mask, or a molded silicone or 3D-printed mask
- Ready-made frames fed to the software by a synthetic camera source or a modified client, with no lens involved at all
02
Two attack classes, two different defenses
Presentation attacks and injection attacks get discussed as one thing, which is convenient for vendors and unhelpful for buyers. A presentation attack puts an artifact in front of a real camera. An injection attack uses no camera at all: it feeds prepared frames into the software as though a lens had produced them.
Only the first is what liveness test results cover. The second has to be addressed separately: on the two phone methods, by establishing that the software and the device requesting the capture are genuine before any frame is assessed; on the webcam method, by running capture on secure terminals.
Presentation: answered at the camera
Liveness detection decides whether what the lens sees behaves like a face in real light rather than like a display or a mask. Capture is ordinary 2D RGB, so the check works on phones people already own instead of a short list of handsets with depth sensors.
Injection: answered before the camera
On the two phone methods, app attestation and device authenticity checks run at every fresh face ceremony, and they are designed to reject an emulator, a repackaged build or a synthetic camera source before prepared frames reach the code that would judge them.
Detect presentation artifacts at capture
A generated face has to be presented somehow, and a display renders and reflects differently from skin. That is why liveness detection treats a deepfake on a monitor as the same class of artifact as a printed photo.
What crosses the network is already spent
A ceremony that passes on either phone method yields one sealed token, good for that sign-in and no other. Nothing durable travels, so recording the traffic today buys an attacker nothing to replay next week.
03
What the independent tests covered
Assertions about liveness are free, and every supplier makes one. What deserves reading is the version an accredited laboratory produced while working to a method somebody else published. ISO/IEC 30107-3:2023 is that method. It prescribes how presentation attack detection must be exercised and how the outcome must be written up, while the taxonomy of attack types sits in the companion document, ISO/IEC 30107-1.
SenseCrypt has liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2. Those tiers come from the iBeta program and not from the standard, and what separates one from the next is the time, skill and budget an attacker is assumed to commit to building the artifact.
Scope is the part to read twice, along with what sits outside it, because the boundary is where security questionnaires tend to get answered badly.
Level 1: common presentation artifacts
A photograph run off at a desk, a face replayed on a handset, a cutout held up to the lens. Minutes to build, and very nearly everything a real population will ever be attacked with.
Level 2: more sophisticated artifacts
A mask molded in silicone or printed in three dimensions for one named person, which costs money, takes time, and needs good reference material. Ask every vendor whether their testing reached this tier.
Recognition is evaluated separately
Face recognition is evaluated in NIST FRTE under Seventh Sense's own name since 2021. The report card is public at https://face.nist.gov/frte/reportcards/11/seventhsense_006.html and it is an evaluation, not a certification.
04
Why the ceremony runs inside the app
No browser can attest to what its camera actually saw. Anyone can build one from source, and a page has no mechanism for showing that the frames it received arrived from a lens rather than from a file on disk. That is why the mobile ceremony lives inside the companion app on an enrolled phone instead of in a tab.
On the two phone methods, before the camera is used, the app establishes that it is the genuine build and that the device is the enrolled one, and it does that at every fresh face ceremony rather than once at setup.
The enterprise webcam method is the exception, and its scope is stated accordingly. It is a deviceless mode offered to enterprise customers rather than as a self-serve flow, and with no attested phone in the ceremony it must run on secure terminals: an unsecured terminal exposes webcam capture to injection attacks such as virtual-camera or video-stream injection. Part of the assurance there comes from the managed workstation and the network it sits on. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor. Contact sales@seventhsense.ai to work out whether it fits your environment.
- App attestation confirms the running app is the genuine SenseCrypt build
- Hardware-backed device keys establish that this is the enrolled handset
- A key produces a signature only when the handset is in an unlocked state
- Emulators, repackaged builds and synthetic camera sources are designed to fail these checks before the capture screen opens
- The key requires an unlocked, attested state that a jailbroken or rooted device is designed to fail
05
What this verifies and what it does not
Language in this market is loose, so this deserves a flat statement. One question gets answered: is the individual now in front of this camera alive, present, and the one who enrolled on this account. Nothing in the result speaks to who that individual is in the world.
Keeping that line visible is what makes the rest of the claims checkable, and it also tells you where your own controls still have to sit.
This is authentication, not identification
Every comparison runs against a single enrolled record. Nothing is searched across a population, for the straightforward reason that no population-wide store of faces exists to search.
No proofing, no KYC, no age estimate
No document is inspected, no third-party record is queried, and no age is estimated at any point. Establishing who somebody is in the world, where that is required, happens before enrollment and remains your work.
It does not police the video call
Authentication is a ceremony between a person, their device and the service. Nothing here should be read as a general deepfake detector for meetings, media or recorded footage.
06
Frequently asked questions
Does SenseCrypt detect deepfakes?
A deepfake shown to a camera is a presentation attack, which liveness detection is designed to reject within the tested attack conditions. SenseCrypt has liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2. A deepfake injected past the camera is a different attack, handled by separate controls: app attestation and device checks on the two phone methods, and secure terminals for the webcam method, because unsecured terminals expose webcam capture to injection attacks.
What exactly did iBeta test?
Presentation attack detection under ISO/IEC 30107-3, at Levels 1 and 2. The first tier covers cheap artifacts: a printed photograph, a face replayed on a handset screen, a paper cutout. The second covers artifacts built for one named target, such as a silicone or 3D-printed mask. Both tiers are defined by the iBeta program rather than by the standard, which sets the method but grades nothing.
Does that testing cover injection attacks?
No, and no testing under ISO/IEC 30107-3 does, whoever performs it. On the two phone methods a separate set of controls addresses injection: app attestation establishes that the running app is the genuine build, hardware-backed device keys establish that the handset is the enrolled one, and a key will produce a signature only when that handset is unlocked. A repackaged build or a synthetic camera source is designed to fail those checks before any frame reaches the code that would have judged it. On the webcam method, capture must run on secure terminals because unsecured terminals expose webcam capture to injection attacks.
Do you need a depth sensor or a particular phone?
No. Capture is 2D RGB from an ordinary camera, which is what keeps the method usable across the phones a real workforce or customer base already carries.
Is this age verification or identity proofing?
No. SenseCrypt authenticates the person who enrolled on the account. Nothing inspects a document, queries a third-party record or estimates an age, and those steps, where you need them, sit upstream of enrollment.
What about the enterprise webcam method?
It is a deviceless mode scoped to enterprise customers, and it must run on secure terminals: with no attested phone, the workstation and the network form part of the assurance, and an unsecured terminal exposes webcam capture to injection attacks. It is arranged through sales@seventhsense.ai rather than enabled self-serve.