Reference · built on requestOperator by FibricSafety, security & compliance

Access Anomaly

Checks badge events against rosters, schedules and area rules. Proposes a credential hold or review ticket for out-of-pattern use.

Request accessPricing ↗

About

A badge that opens a server room in the small hours, a credential used at two sites within minutes, a contractor's card still opening doors after the job ended. Each is one line in an access control event log that nobody reads in full. Access Anomaly reads door events from your access control platform as they arrive, then checks each one against the shift roster, the person's status in your directory, and the area rules you set per door group.

When an event does not fit, it proposes a credential hold or a review ticket with the events that led to it. You approve the hold. The credential stays active until you do.

This is a reference listing. It documents what Fibric would read from Access Anomaly and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Access accepted, access denied, door held open and door forced events, by door, credential and time, through Verkada Access Events or Brivo Access Events
  • Shift rosters and time off from your scheduling platform, such as Deputy or When I Work, to know who is expected on site and when
  • User status in your directory through the Okta Users API or Microsoft Entra ID, so a suspended or deactivated person is not treated as staff
  • Access groups and access levels that say which doors each credential should open and during which schedule
  • Cardholder presence and last-seen events on platforms that report them, such as Kisi presences
  • Open review tickets in Jira Service Management or ServiceNow, so a credential already under review is not proposed twice

Proposed actions

  • Target capability: propose suspending a credential on your access platform, through Brivo's suspended status or Verkada's end date, for your approval
  • Target capability: propose a review ticket in Jira Service Management or ServiceNow listing the events, the roster entry, and the rule that did not fit
  • Target capability: propose a Teams or Slack notice to the security lead when a door forced or door held event has no matching work order
  • Target capability: propose an exception for a person and door group, such as approved after-hours work, so the pattern is not flagged again
  • Target capability: propose a weekly list of credentials used outside their schedule, grouped by person and site

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hold a contractor's card after the job ends

    A contractor's credential in Brivo keeps opening the loading dock after the Deputy roster shows no shifts. Access Anomaly proposes the suspended status on the credential and a Jira Service Management ticket for the site lead.

    With Brivo Access, Deputy, Jira Service Management

  • Catch a credential used at two sites at once

    One card badges in at two buildings within minutes. The operator proposes a Verkada end date on the credential and a Teams notice to security, with both events attached.

    With Verkada, Microsoft Teams

  • Stop a deactivated person's badge quietly working

    Okta marks a person deactivated, but the cardholder record in Kisi is still active and the card is used that evening. The operator proposes a hold and a ServiceNow ticket.

    With Okta, Kisi, ServiceNow

Requirements

  • An access control connector that serves door events with credential, door and time, such as Verkada, Brivo, or Kisi
  • A scheduling or HR connector with shift rosters per person and site, such as Deputy, When I Work, or Workday
  • A directory connector that reports user status, such as Okta or Microsoft Entra ID, with the employee id matched to the cardholder record
  • A ticket connector for review tickets, such as Jira Service Management or ServiceNow
  • Area rules per door group: which roles may enter, and during which hours, entered by you
Authentication
Access Anomaly holds no credentials of its own. Door events, rosters, directory status and tickets come through the connectors you have connected, and every hold or ticket is proposed through those same connectors.

Limits

  • A person without a roster entry, such as a salaried employee with no shifts, is judged against area rules and directory status only.
  • It never suspends a credential, changes an access level, or opens a door on its own. Every hold is a proposal a person approves.
  • Video is not reviewed. Where a camera link exists for the door and time, it is attached to the proposal for a person to view.
  • Brivo serves access events in windows of up to 24 hours per request, so history from before the operator is connected is loaded in slices.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Access Anomaly ↗

Questions and answers

Who approves a credential hold?
A person you name, such as the security lead. The proposal shows the door events, the roster entry, the directory status, and the rule that did not fit. Approve it, edit the scope, or dismiss it. Nothing changes on the access platform until then.
What is recorded when a hold is approved or dismissed?
A receipt for every proposal: the events that triggered it, who approved or dismissed it, what was written to the access platform or ticket system, and how to reverse it. Dismissed proposals stay in the record so you can see which patterns were judged normal.
Can it open or lock a door?
No. It reads door events and proposes credential holds and tickets. It never sends a door command, changes a schedule, or edits an access level. Those remain actions a person takes in the access platform.
Ask about Access Anomaly

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy