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 a liveness certificate covers. The second has to be defeated earlier, by establishing that the software and the device requesting the capture are genuine before any frame is assessed.
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
App attestation and device authenticity checks run at every sign-in. An emulator, a repackaged build or a synthetic camera source fails them, so the prepared frames never reach the code that would have judged 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 a deepfake on a monitor fails for the same underlying reason a printed photo does.
What crosses the network is already spent
A ceremony that passes on either mobile 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 the NIST Face Recognition Technology Evaluation under Seventh Sense's own name, participation since 2021. The report card is public at https://pages.nist.gov/frvt/reportcards/11/seventhsense_000.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.
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 sign-in rather than once at setup.
The enterprise webcam method is the exception, and its scope is stated accordingly: it is offered to enterprise customers on a trusted customer network rather than as a self-serve flow, because part of the assurance there comes from the managed workstation and the network it sits on rather than from an attested phone. Contact sales@seventhsense.ai to work out whether it fits your environment. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
- 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 fail before the capture screen opens
- A jailbroken or rooted device cannot reach the unlocked, attested state the key requires
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, and liveness detection is what rejects it. 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, blocked earlier by app attestation and device checks.
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. A separate set of controls covers 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 fails all three before any frame reaches the code that would have judged it.
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 scoped to enterprise customers on a trusted customer network, because the workstation and the network form part of the assurance there rather than an attested phone. It is arranged through sales@seventhsense.ai rather than enabled self-serve.