Eliminate Dormant Account Access Risk & SaaS Waste

Outcome

Security and IT teams gain a continuously maintained view of every inactive and dormant account across every connected application — with standing access still intact — and drive revocation through structured, accountable remediation campaigns. Dormant accounts that represent a persistent, unmonitored attack surface are identified the moment they cross the inactivity threshold, not discovered months later during a breach investigation or a compliance audit. The result is a smaller standing attack surface, reduced license spend, and an auditable record of every access revocation.

The dormant account problem in numbers: Industry research consistently shows that 15 to 30 percent of accounts in a typical enterprise environment are inactive — still provisioned, still carrying full entitlements, but with no meaningful recent activity. Each one is an open door: a valid credential an attacker can use without triggering any behavioral anomaly, because there is no expected behavior to deviate from. Dormant accounts are low-noise, high-value targets. Eliminating standing access on them is one of the highest-return identity security investments available.

Why this is hard without Oleria

Identifying dormant accounts with standing access sounds like a reporting query. In practice, it requires reconciling last-activity data across dozens of systems, applying a consistent dormancy definition, and distinguishing accounts that are genuinely inactive from those that simply authenticate infrequently by design. Without a unified platform, organizations face:

· Last-login data from the IDP is not the same as inactivity. A user who last authenticated to Okta or Entra ID last week may not have opened a specific SaaS application — the one their access matters for — in six months. IDP last-login timestamps measure authentication events, not application-level activity. Relying on IDP data to detect dormant SaaS access produces systematically false negatives: accounts that appear active at the IDP layer but have long since stopped using the applications they are provisioned for.

· No cross-application dormancy view. Each SaaS application holds its own last-activity timestamp — last login date, last API call, last record modification. There is no native mechanism to aggregate these signals across applications to produce a single, per-identity dormancy picture. Building it manually requires exports from every system, reconciliation by identity, and a threshold decision — a process that takes days and is stale before it is complete.

· No consistent definition of dormancy. Different teams apply different thresholds: 30 days, 90 days, 180 days, "since the last review." Without a single, consistently applied dormancy definition across all applications and identity types, dormancy findings cannot be compared, trended, or acted on at scale.

· Standing access is not automatically revoked when an account goes dormant. Even when a dormant account is identified, revoking its standing access requires a deliberate action in each system where the account holds entitlements. Without a workflow that surfaces the full access footprint of a dormant account and tracks revocation to completion, access is revoked in some systems and silently left intact in others.

· Offboarding gaps create a persistent dormant account population. When employees leave, accounts in SaaS applications that are not part of the IDP deprovisioning workflow remain active indefinitely. These are not just dormant accounts — they are accounts whose owner no longer works for the organization, with full standing access, and no one monitoring them.

· The dormant account population is never fully known. Without continuous monitoring, the dormant account population can only be known as of the last audit. New dormant accounts accumulate between reviews — employees go on extended leave, contractors finish engagements, roles change — and the gap between the last audit and today is always unknown.

‍

What Oleria delivers

Oleria Trustfusion ingests application-level activity signals from every connected system, applies a consistent dormancy calculation per identity and per application, and surfaces dormant accounts with standing access as continuously maintained posture findings — prioritized by access scope, privilege tier, and identity type, with structured remediation tracked to confirmed closure.

Application-level activity signals, not IDP last-login.

Oleria measures dormancy at the application level — using the last meaningful activity signal from each connected SaaS application, not just the last IDP authentication event. An account that last authenticated to Okta yesterday but has not opened Salesforce in 90 days is dormant in Salesforce. That distinction is invisible without application-level activity data, and it is the distinction that matters for access revocation decisions.

Configurable dormancy thresholds by identity type and application.

Dormancy thresholds are configurable per account type and application sensitivity. Standard user accounts may apply a 90-day window; privileged accounts a 30-day window; external and contractor accounts a shorter window reflecting their engagement lifecycle. Different thresholds for different risk tiers ensure that the highest-risk dormant accounts are caught first and acted on with the shortest SLA.

Standing access inventory for every dormant account.

When an account is flagged as dormant, Trustfusion surfaces its complete standing access footprint — every role, every permission, every group membership, across every connected application where it holds entitlements. Remediation is not just "suspend the account in the IDP." It is a complete picture of every access relationship that needs to be revoked.

Privilege-weighted dormancy prioritization.

Dormant accounts are risk-scored based on their access footprint. A dormant account with no privileged access in a low-sensitivity application is a low-priority cleanup item. A dormant account with admin rights in Snowflake, GitHub, and Salesforce is a critical finding requiring immediate action. Prioritization is automatic and proportionate to actual risk.

Offboarding gap detection.

Oleria cross-references every account's activity status with HR and IDP employment records. Accounts that are dormant because their owner has left the organization — rather than through ordinary inactivity — are surfaced as post-offboarding persistence findings, the highest-severity category of dormant account finding. These are not just cleanup items; they are accounts that should not exist at all.

Posture Campaigns for structured revocation.

Dormant account findings are packaged into Posture Campaigns with assigned owners, severity tiers, and due dates. IT admins and application owners receive actionable assignments with the full dormant account profile and the recommended action: suspend, deprovision, or initiate a review with the account's manager before acting. Revocation is tracked to confirmed closure across every application in scope.

Continuous monitoring — no gap between reviews.

Dormancy posture is re-evaluated continuously as activity data is refreshed. The moment an account crosses the configured inactivity threshold, a finding is generated. The dormant account population is always current — not a snapshot from the last quarterly audit.

How it works

Stage 1 — Continuous Ingestion of Multi-App Activity Logs and HR Lifecycle Attributes: Oleria connectors pull last-activity timestamps from each connected SaaS application — last login date, last API call, last record access or modification — alongside full account and entitlement data. IDP connectors (Okta, Entra ID) provide authentication event timestamps and account status. HR system connectors provide employment status and termination dates. All activity signals are ingested continuously so dormancy calculation reflects the current state of each account, not a periodic snapshot.

Stage 2 — Granular Application-Level Dormancy Computations and Risk Verification: For each account in each connected application, Oleria Trustfusion calculates the days since last meaningful activity using the application-level signal — not the IDP last-login. Where multiple activity signal types are available (login, API call, content modification), the most recent is used. The calculated inactivity period is compared against the configured threshold for the account's identity type and privilege tier. Accounts at or beyond the threshold are classified as dormant. Employment status from HR is applied to distinguish ordinary dormancy from post-offboarding persistence.

Stage 3 — Dynamic Standing Access Mapping and Financial Cost Assessment: For every dormant account, the Access Graph resolves its complete standing access footprint: every role, permission, group membership, and entitlement across every connected system. Dormancy findings are risk-scored based on the combination of inactivity duration, privilege tier, access scope, and identity type. Post-offboarding accounts are automatically elevated to critical severity. License assignment is flagged where present, enabling cost-recovery alongside security remediation.

Stage 4 — Multi-Tier Visualization, Posture Campaign Remediation, and Closure Audits: Findings surface in the Posture Dashboard filterable by dormancy duration, privilege tier, identity type, and application. Posture Campaigns route findings to the right owner — IT for deprovisioning, application owners for review, or the account's manager for confirmation before action. When access is revoked, Trustfusion confirms the change in the Access Graph and closes the finding. The complete chain — dormancy detected, owner assigned, access revoked, closure confirmed — is retained as timestamped audit evidence.

What good looks like

A mature dormant account program produces a measurably smaller standing attack surface, with continuous visibility and accountable remediation replacing the periodic audit cycle:

· Dormant account population known at all times. The full set of inactive and dormant accounts across every connected application — with their standing access footprint — is visible in Trustfusion at any moment. The size of the dormant account population is tracked as a security KPI and reported to leadership on a defined cadence.

· No dormant privileged accounts with standing access. Any account carrying a privileged role that crosses the dormancy threshold generates a critical finding with a short remediation SLA — hours for highly privileged accounts, days for standard privileged accounts. Zero open dormant privileged account findings at any given time is the target state.

· Post-offboarding accounts eliminated within 24 hours. Accounts identified as belonging to terminated employees — through HR or IDP status cross-reference — are flagged immediately and have their standing access fully revoked across all connected applications within 24 hours. No former employee retains active access to any corporate system.

· Dormancy SLA enforced by tier. All open dormant account findings have an assigned owner, a due date based on the account's severity tier, and a tracked status. Mean time to revoke standing access from dormant accounts is measured per tier and trends downward over time as the program matures.

· Revocation complete across all applications, not just the IDP. When a dormant account is remediated, standing access is revoked across every application where the account holds entitlements — not just the IDP account suspended. Trustfusion confirms closure in the Access Graph, so partial revocations are not treated as complete.

· License reclamation tracked alongside security remediation. Every dormant account with an active license assignment is flagged for reclamation. License recovery is reported to finance and IT as a quantifiable return on the security program, linking identity hygiene to concrete cost savings.

· Audit evidence on demand. For any dormant account finding — past or current — the full record is available from Trustfusion: when dormancy was detected, what access was revoked, who actioned it, and when closure was confirmed. Compliance teams can produce this evidence for SOX, SOC 2, ISO 27001, and PCI DSS auditors without manual report assembly.

‍

Frequently Asked Questions

How does Oleria define dormancy, and can we configure the thresholds?

Oleria defines dormancy as the elapsed time since the last meaningful application-level activity for a given account in a given application. "Meaningful activity" is defined by the activity signals available from each application connector — typically last login date, last API call, or last content access or modification. Dormancy thresholds are fully configurable by account type (employee, contractor, external), privilege tier (standard, privileged, highly privileged), and application sensitivity. Common configurations apply 90-day thresholds for standard accounts, 30-day thresholds for privileged accounts, and shorter windows for contractor and guest accounts. Thresholds can differ by application — a 30-day threshold on a production database admin account and a 90-day threshold on a standard productivity tool account, for example.

Why does Oleria use application-level activity rather than IDP last-login?

IDP last-login measures when a user last authenticated through the identity provider — which may be to any application integrated with the IDP, or simply to maintain a session token. It does not measure whether a user has actually used a specific application. A user who logs in to check their email every day but has not opened Salesforce in four months will show as "active" in the IDP. Oleria's application-level activity signals measure actual engagement with each specific application — the signal that determines whether the account's access in that application is serving an active business purpose or represents standing exposure.

What is the difference between a "dormant" account and an "inactive" account in Oleria?

In Trustfusion, dormancy refers to the condition of an account that has not shown meaningful application-level activity within the configured threshold period — the account exists, is provisioned, and holds standing access, but is not being actively used. Inactive refers to accounts that have been disabled or deactivated at the IDP or application level — the account exists in the system but cannot be used to authenticate. Both are surfaced as posture findings because both represent standing access that should be reviewed: dormant accounts because they are an exploitable open door; inactive accounts because their entitlements may not have been fully revoked despite the account being disabled.

How does Oleria handle accounts that are legitimately infrequently used — seasonal workers, on-call roles?

Oleria's dormancy framework is designed to accommodate legitimate infrequent use patterns. Threshold configuration allows different windows for different account types and roles. For accounts with a documented pattern of legitimate infrequent use — seasonal employees, on-call responders, board members — a longer threshold can be applied, or the account can be tagged with an exception classification that suppresses dormancy findings while the documented business justification remains valid. Exception classifications are recorded in Trustfusion and expire on a configured schedule, requiring active renewal rather than persisting indefinitely.

Does Oleria revoke access automatically, or does it require manual approval?

Trustfusion supports a spectrum from fully guided to automated remediation. In guided mode — the default starting point for most organizations — dormant account findings are assigned to owners via Posture Campaigns, who confirm the action and execute revocation through standard IT workflows. This approach preserves human judgment for accounts where context matters: a dormant account might belong to an employee on medical leave, a contractor between engagements, or a break-glass account that should never be fully deprovisioned. For high-confidence scenarios — such as accounts dormant beyond 180 days with no active HR record and no privileged access — automated suspension or deprovisioning workflows can be configured, with revocation confirmed in the Access Graph and recorded as audit evidence.

How does this use case connect to license cost recovery?

Every dormant account with an active license assignment is flagged in the Access Inventory with the license type and application. The aggregate count of licensed dormant accounts — and the associated license cost — is surfaced as a posture dashboard metric. When standing access is revoked from a dormant account and the license is reclaimed, Trustfusion records the reclamation event. Finance and IT teams can use this data to track license recovery as a measurable return on the security program, connecting identity hygiene directly to SaaS cost management.

Which compliance frameworks require action on dormant accounts?

SOX ITGC requires periodic user access reviews and timely deprovisioning — dormant accounts with standing access are a direct gap in this control. SOC 2 Type II (CC6.2 and CC6.3) requires that access be provisioned and de-provisioned based on need, with evidence that stale access is identified and removed. ISO/IEC 27001 (A.9.2 User access management) requires that access rights be reviewed at regular intervals and adjusted or revoked when no longer needed. PCI DSS v4.0 (Requirement 8.2.6) explicitly requires that inactive user accounts be removed or disabled within 90 days of inactivity. NIST SP 800-53 (AC-2) requires account management processes that include disabling or removing inactive accounts. Trustfusion's dormancy findings, remediation campaigns, and closure records provide the continuous monitoring and audit evidence these frameworks require.

Find and eliminate standing access from every inactive account before it gets exploited