Reference · built on requestOperator by FibricSafety, security & compliance

Badge Hygiene

Matches cardholder records to HR and directory status. Proposes deactivation of dormant, orphaned and leaver credentials.

Request accessPricing ↗

About

Access control platforms accumulate credentials that no longer belong to anyone who should hold them. A person leaves and HR closes the record, but the card is never returned. A contractor's badge outlives the contract. A cardholder was created by hand and matches no employee at all.

Badge Hygiene reads the cardholder list from your access platform, the employee list and termination dates from your HR system, and user status from your directory, and joins them on employee id and email. It then proposes deactivations in three groups: leavers, whose HR or directory record is closed; dormant credentials, unused for longer than the period you set; and orphans, with no HR or directory match. You approve each group or each line.

This is a reference listing. It documents what Fibric would read from Badge Hygiene 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

  • Cardholder records and their credentials from your access platform, with employee id and email, through Verkada Get All Access Users or Brivo List Users
  • Employee records, employment status and termination dates from BambooHR, Workday, or Rippling, and field-change webhooks where the platform sends them
  • User status in Okta or Microsoft Entra ID, including suspended and deactivated accounts
  • Last credential use per cardholder, derived from door events on the access platform
  • Card assignments and shares on platforms that model them apart from users, such as Kisi card_assignments and shares

Proposed actions

  • Target capability: propose deactivating a leaver's credentials, through Verkada Set End Date for User or Brivo Revoke User Credentials, for your approval
  • Target capability: propose deactivating credentials unused for longer than the period you set, listed by cardholder and last use
  • Target capability: propose a review list of orphaned cardholders with no match in HR or the directory, for the badge office to resolve
  • Target capability: propose a Teams or Slack notice to the badge office summarizing what was deactivated and what is waiting on a person

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

What you can build

  • Close out a leaver on the day HR does

    BambooHR fires a webhook when an employee's status changes to terminated. Badge Hygiene proposes an end date on the person's Verkada access user and a Teams notice to the badge office.

    With BambooHR, Verkada, Microsoft Teams

  • Find badges that have not opened a door in months

    Reading Brivo door events, the operator lists credentials with no accepted event inside the period you set and proposes revoking them, one line per cardholder.

    With Brivo Access

  • Reconcile the access platform against Okta

    Every week the operator joins Kisi members to Okta users and lists members with no Okta match or a deactivated one, proposing deactivation for the second group and review for the first.

    With Kisi, Okta

Requirements

  • An access control connector that lists cardholders with employee id or email, such as Verkada, Brivo, Kisi, or LenelS2 OnGuard
  • An HR connector with employment status and termination date, such as BambooHR, Workday, or Rippling
  • A directory connector with user status, such as Okta or Microsoft Entra ID
  • A join key: the employee id or email held on the cardholder record must match the HR or directory record
Authentication
Badge Hygiene has no login of its own. It reads cardholders, employees and directory users through the connectors you have connected, and each deactivation is proposed back through the access platform connector.

Limits

  • Cardholders with no employee id or email on the access platform cannot be matched and are listed as orphans until a person fills the field.
  • Deactivation is proposed only where the access platform's API allows it. Physical cards are not collected; that stays with the badge office.
  • The dormant period is yours to set. Platforms that do not serve a last-used value fall back to the door events the operator has seen.
  • It does not delete cardholder records. Deactivation leaves the record and its history in place.

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 Badge Hygiene ↗

Questions and answers

Does a leaver's credential switch off automatically?
No. When HR or the directory closes the record, the operator proposes the deactivation. A person approves it, and only then is the end date or revocation written to the access platform. You can set the proposal to reach the approver at once rather than in the weekly batch.
What if the HR record and the cardholder disagree?
The cardholder goes on the orphan review list with both records side by side. The operator does not guess which is right. A person resolves the match or fills the missing employee id, and the next run picks it up.
What trace is left after a deactivation?
A receipt per credential: the HR or directory evidence, the last door event seen, who approved it, the write made to the access platform, and how to restore the credential. The receipts form the access review evidence for the period.
Ask about Badge Hygiene

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