A face is a convenient credential and a badly protected one. Anyone can print it, and most people publish it. Face-based access is therefore only as good as the check that decides whether it is looking at a person or at a picture of one.
How It Is Built
Regulated access to premises is assembled from parts the platform already has, rather than from a separate product. You create a person list holding the people entitled to enter, you point FaceTrack Pro at the camera on the entry point, and you configure the connection to the lock. A recognized face on the list produces a "Match" event; a face that is not on it produces "No match". What happens next is the door’s business, not the camera’s.
IREX is not a lock and does not sell one. It recognizes the face and drives the access-control hardware you already own: the documentation describes interfaces to external devices such as smart locks, Sigur is documented as an access-control integration and Netping as an external device, and beyond those any alarm monitor can push its events, with frames, to any endpoint reachable over HTTP. A face match opening a door is the worked example in the integration documentation.
The number that decides everything is the similarity threshold, and the guidance on it is deliberately unglamorous: set it with care, because it is the balance between refusing people who belong and admitting people who do not. On a door, unlike on a watchlist, both errors have someone standing in front of them. That threshold, and the placement of the camera that feeds it, are what a commissioning visit exists to settle.
Alongside the match, the platform estimates a spoofing probability for the face it is looking at and shows it as a percentage on the event, beside the similarity score. It is not only a gate: the estimate is stored on the event and is searchable, so "show me every high-spoofing-probability event on the staff entrance last month" is a query rather than a review of a month of video.
The Settings
The same module runs both, but almost every setting moves. A concourse camera should try hard on a poor face at a distance; a reader should refuse to decide until the right person is close enough and facing it.
A person list holds the people entitled to enter, imported in batch or added one at a time, and access to the list itself is granted per user group. Nobody outside the list is recognized: there is no open recognition of whoever walks up.
The similarity score a match has to clear. The documented instruction is to pay special attention to it and to hold the balance between false negatives and false positives, because on a door both are expensive in different ways.
Ignores faces smaller than a size you set by dragging a rectangle on the frame. This is what stops a reader deciding "match" or "no match" too early, while the candidate is still walking up and too far from the lock to be judged.
Suppresses recognition on faces tilted or panned beyond limits you set, which lowers the error rate directly. A door is the one place you can reasonably insist the subject looks forward.
While a face stays in the frame, recognition repeats every interval you set and emits a new event on each result. Somebody who was not recognized at three meters is recognized at one, without asking them to step away and try again.
Recognition runs in a Highest accuracy or a Minimum delay mode, and on a door that is a real choice, not a slider to leave alone. GPU acceleration is available for the recognition itself where throughput matters.
On Camera
A phone, a tablet and a sheet of paper. These are the attacks a liveness check exists for, and they are cheap enough that a door protected only by recognition is not protected.
The commonest presentation attack there is, because the material is already public. What the camera receives is a flat, evenly lit, perfectly still face, which is exactly what a liveness check is looking for.
A larger screen fills almost the whole field of view and can be held at the right height and distance. Size and framing are not what gives it away, which is the point of scoring the image rather than measuring the face.
Paper texture, white margins, a curl at the corner: the cheapest attack of the three and the one that needs no device at all. It is also the one a door with no liveness check will open for.
The Check
The platform estimates how likely it is that the face on camera is a presentation rather than a person, and displays that spoofing probability as a percentage on the event card, next to the similarity score, where an operator reviewing an entry can see both at once. It is an estimate offered for judgment, not a verdict announced after the fact, and it is exposed on the event through the API alongside the other face attributes.
Because the estimate is stored on the event, a search can run on spoofing probability like any other criterion. That turns anti-spoofing from a gate into an audit surface: probe attempts against a specific door over a period, patterns by time of day, repeated attempts on the same entry point. A door that quietly refused three presentations last Tuesday is a finding, and it is only a finding if somebody can query for it.
See Ask IREX & Video Search →Spoofing detection was strengthened specifically to improve suspect identification in the field, so the estimate is not confined to entry points: it travels with face events across the estate, which matters wherever a camera can be shown a photograph rather than a person. On the recognition side it is one more attribute to weigh before an officer acts.
Wiring It In
Sigur is documented as an access-control integration and Netping as an external device, both created under Settings and granted per user group so only the right teams can reach a given door. The guide describes the pattern generically as interfaces to external devices such as smart locks, which is the honest scope: IREX recognizes and signals, the access-control system decides and actuates.
Where there is no named integration, an alarm monitor can push its events with frames to any endpoint reachable over HTTP, and the REST API covers lists, monitors and users. A face match opening a door is the documented worked example. If your access-control platform accepts an HTTP call, it can be driven from a match; if it emits one, its events can arrive in the IREX console.
A "No match" event is a first-class event with its own priority, so a tailgating review, an out-of-hours attempt or a repeated presentation at a sensitive door becomes an alarm monitor with a response protocol rather than a line in a log nobody opens. Notifications reach the responder through the Sover secure messenger with the frame and a playback link attached.
See Real-Time Alerts & Evidence →Requirements
Ethical AI
Access control is the IREX use case where the system is closest to acting on its own, so the constraints matter more here, not less.
No, and it is not sold as one. IREX supplies the recognition, the liveness and spoofing estimate, the event and the audit trail; your access-control platform keeps the doors, the readers, the credentials and the decision to open. The connection is either a documented integration, Sigur for access control and Netping as an external device, or the alarm-monitor webhook, which can call any endpoint reachable over HTTP. Nothing about the lock estate has to be replaced.
The platform estimates a spoofing probability and reports it as a percentage on the event, and that estimate is searchable afterwards. IREX publishes no detection rate for it, in line with the standing policy against unsourced accuracy figures and "guaranteed detection" wording. If spoofing resistance is a decision criterion, make it a written pilot criterion: run the presentations you actually care about against your own readers and cameras, and the measured result goes into the contract.
That is precisely the attack the liveness check exists for, and the three frames on this page are the cheap versions of it: a phone, a tablet and a printed sheet. What the check evaluates is whether the camera is seeing a live face or a presentation of one, and the resulting probability is put in front of the operator and stored on the event. Design the door so a refusal has a sensible route past it, because no biometric check should be the only thing between a legitimate person and the room they work in.
Any camera that supports ONVIF or streams RTSP with H.264 or H.265, but the imaging bar is the real constraint: more than 500 pixels per meter in the region of interest and at least 50 pixels eye to eye, at head height or slightly above, 1.5 to 3 m, with tilt within +5°, no backlight and no reflections. A corridor camera almost never meets that. A camera specified for the entry point usually does.
It emits a "No match" event, which you can prioritize and route like any other event, and the re-recognition interval means it keeps trying while the person is in frame rather than deciding once at the wrong distance. Operationally this is why the minimum face size setting exists: a reader that decides too early produces refusals that were never really decisions.
That is a different module and a better fit for the job. Plate reading with a list of permitted vehicles covers a vehicle gate, and the same webhook that opens a door on a face match opens a barrier on a plate match.
It runs on its own and alerts a person. Detections are signals for a human to verify: no response runs autonomously, and the verification and decision are logged against the same Case ID as the detection.
Keep Reading
One entry point, one enrolled list, and the presentation attacks you actually worry about. That is a two-week pilot, and it settles the question better than a datasheet.