Reference · built on requestOperator by FibricIT & reliability

Stale Accounts

Finds accounts idle beyond policy in Okta, Entra ID, AWS, and GitHub, checks the HR roster, and proposes suspending them.

Request accessPricing ↗

About

Accounts outlive the people and jobs that needed them. A contractor's Okta login, an AWS access key nobody has used since a migration, a GitHub seat that only ever authenticated through a token. Stale Accounts reads the last sign-in and last key use that each system already records: lastLogin on Okta users, signInActivity on Microsoft Entra ID users, password_last_used and access_key_1_last_used_date in the AWS IAM credential report, and the Dormant Users report in a GitHub Enterprise account.

It checks each idle account against the HR roster, so a person on leave is not treated like a person who left. Then it proposes one action per account: suspend, disable, or set a key Inactive. You approve each one. The record shows the last activity date, the roster status, and how to reverse the change.

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

  • User records in Okta with lastLogin, status, and statusChanged, read through the Users API
  • signInActivity on Microsoft Entra ID users: lastSignInDateTime, lastNonInteractiveSignInDateTime, and lastSuccessfulSignInDateTime
  • The AWS IAM credential report: password_last_used, access_key_1_last_used_date, access_key_2_last_used_date, and user_creation_time per user
  • Organization members in GitHub through GET /orgs/{org}/members, and the Dormant Users report from a GitHub Enterprise account
  • lastLoginTime and suspended on Google Workspace users through the Directory API
  • The employee roster and its changes: BambooHR employees marked Inserted, Updated, or Deleted, or Rippling worker changes with offboardings

Proposed actions

  • Target capability: propose Suspend a user through POST /api/v1/users/{id}/lifecycle/suspend for an Okta account idle beyond your policy
  • Target capability: propose setting accountEnabled to false on a Microsoft Entra ID user, or suspended to true on a Google Workspace user
  • Target capability: propose setting an unused AWS access key to Inactive with UpdateAccessKey, with deletion as a later, separate proposal
  • Target capability: propose removing a dormant member from a GitHub organization through DELETE /orgs/{org}/members/{username}
  • Target capability: propose Deactivate a user in Okta once the roster shows the person has left and the suspension has held

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

What you can build

  • Suspend Okta users who left the roster

    When BambooHR marks an employee Deleted and the Okta user still shows ACTIVE, the operator proposes a suspension. The proposal shows the lastLogin date and the roster change. You approve, and the record keeps both.

    With Okta, BambooHR

  • Retire dormant GitHub seats

    Members listed in the Dormant Users report are matched against Rippling worker changes. Contractors whose engagement ended get a proposed removal from the organization. Service accounts that authenticate by token are listed separately, not proposed.

    With GitHub, Rippling

  • Disable Entra ID accounts with no sign-in

    Users whose lastSignInDateTime and lastNonInteractiveSignInDateTime both fall outside your window, and who are not on leave in Workday, get a proposed accountEnabled change. Guests are proposed in their own batch.

    With Microsoft Entra ID, Workday

Requirements

  • An identity connector such as Okta, Microsoft Entra ID, or Google Workspace with permission to read users and, where proposals are carried out, suspend them
  • For Microsoft Entra ID, a P1 or P2 license and AuditLog.Read.All, which signInActivity requires
  • For AWS, iam:GenerateCredentialReport and iam:GetCredentialReport, plus iam:UpdateAccessKey where keys are to be disabled
  • An HR connector such as BambooHR, Rippling, or Workday, so leave, transfers, and departures are read from the roster and not guessed
  • An idle threshold per system, set by you. GitHub's own dormant definition is 30 days; the other systems define none
Authentication
Runs on the read and write grants of the identity, cloud, code hosting, and HR connectors you attach. Nothing is stored beyond what those connectors already hold.

Limits

  • The AWS credential report is generated at most once every four hours. Password use is recorded once per five minutes, key use once per fifteen.
  • GitHub counts SAML sign-in, pushes, and comments as activity. Token, SSH key, or GitHub App access does not, so a bot seat looks dormant.
  • Okta updates a user's state at login or on a lifecycle event, never on a sweep. A user who never signed in has lastLogin null.
  • It proposes suspend before deactivate. It never deletes a user, a key, or a seat. A person absent from the roster is flagged, not suspended.

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 Stale Accounts ↗

Questions and answers

What do I approve for each account?
One action for one account: suspend, disable, set a key Inactive, or remove a seat. The proposal names the system, the last activity date the system recorded, the roster status, and the reversal step. You can approve, change the action, or dismiss it.
What record is left after a suspension?
A receipt per approval: the account, the evidence dates, who approved, when the change was applied, and how to undo it. In Okta the change also appears in the System Log. In AWS the key status shows in the next credential report.
Will it ever delete an account or a key?
No. It proposes suspend or Inactive first and deactivate only later, as a separate proposal. Deleting a user, a key, or a seat is not something it proposes. If a person is missing from the roster entirely, the account is flagged for review rather than suspended.
Ask about Stale Accounts

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