Local Anti-Passback.
Making credential-sequence rules clear without hiding the operational exceptions.
A security rule with real-world consequences.
Local Anti-Passback checks the order in which a credential is used at entry and exit points within a defined local scope. These seven supplied design screens replace the earlier portfolio concepts. Their interface content illustrates the design; it is not evidence of released behavior or measured results.
A rule that protects access can distort attendance.
Organisations want employees to follow a strict entry-and-exit sequence: you badge in, you badge out, and you can’t enter twice without leaving first. This protects against shared credentials and out-of-order access. In highly secure environments, where an unrecorded or duplicated entry is a real risk, this rule (Anti-Passback) is essential.
Attendance and payroll
The same rule also affects attendance. When someone slips through behind a colleague, or an exit isn’t recorded, the system’s record of who is inside stops matching reality. This distorts the attendance logs that payroll and HR depend on.
Security versus flexibility
Administrators were therefore stuck between security and flexibility. High-security sites needed strict enforcement, while others needed a way to flag violations without disrupting daily operations and attendance. They also needed to understand what each setting would do before turning it on, and to investigate violations afterwards.
The design challenge
Create a configurable Anti-Passback experience that gives secure sites strict enforcement, lets other sites flag violations without blocking people, and keeps access and attendance records clear and trustworthy.
Understand the rule before drawing the interface.
I owned the original work from requirements and research through flows, stakeholder reviews, and developer updates. The competitive review included Matrix, iDCube, HID, and ZKTeco. The available notes identify that review, but do not substantiate individual competitor findings or usability-test results.
Primary user
Security and access-control administrators need predictable door behavior and enough context to investigate an exception.
Research focus
How are Hard and Soft consequences explained? How are reader direction, timed restrictions, and audit exceptions exposed?
Scenario mapping
Valid entry and exit, repeated entry, and missed reads informed the flow. Anti-passback can identify sequence anomalies; it does not physically prevent tailgating.
Three modes. Three explicit consequences.
The design keeps the original Hard, Soft, and Timed model, but puts the consequence beside each choice. These descriptions follow the source document’s expected behavior; the exact product implementation still needs specification confirmation.
Soft — allow and record
Access continues, while an out-of-sequence attempt is recorded for administrative review.
Hard — deny and record
An out-of-sequence attempt is denied and the violation recorded. A five-minute expiry was discussed as a proposal, not confirmed shipped behavior.
Timed — restrict repeated use
Expose the configured waiting interval only when this mode is selected. Confirm whether the timer applies to the reader, door, or another defined local scope before implementation.
Make security configuration scannable.
The access-point list places reader setup, door state, MFA, and anti-passback status in a consistent table. Search and policy filtering support finding a door before changing its settings. Counts are interface content, not product impact.
Keep activity and door context together.
The door overview pairs location and reader configuration with a local anti-passback summary. Recent transactions sit below, while assigning users, opening the door, and configuring the rule remain separate actions.
Explain the consequence at the point of choice.
Blue identifies the selected mode and primary actions. Each mode places its consequence beside the choice, with a policy summary explaining the sequence at the right. Notifications remain a separate group. The screens show proposed timer and offline behavior, not independently verified product specifications.
The selected Hard mode exposes a violation expiry timer and explains the blocked-entry consequence.
Entry stays permitted; a contextual notice explains that sequence violations are recorded.
The single-reader example exposes a minimum wait time and a policy summary for credential reuse.
Selection should be visible, not remembered.
The supplied recipient dialog uses checkboxes, a selected count, and a row checkmark to make the pending selection visible. Confirming recipients is distinct from saving the enforcement rule.
Make exceptions traceable.
Access history brings the person, door, event, credential, direction, and time together. Event descriptions distinguish a Hard violation, a Soft violation, and a waiting interval that has not elapsed. Red signals denied access; green signals granted access. These records illustrate the proposed design, not real operational activity.
Clarity is part of the security model.
The original feature earned stakeholder and CEO sign-off and reached developer handoff. That belongs to the earlier work, not these screens — so no measured impact or shipped state is claimed here. What stayed with me: high-consequence settings need explicit rules, visible exceptions, and a way back people can understand.