oleria

The reality

NHIs are built to outlive their purpose. A service account spun up for a one-off integration runs for a decade. An API token issued for a vendor pilot still authenticates after the pilot wrapped. There's no expiry, no renewal, no review. The credential silently waits to be compromised. This is the textbook OWASP NHI7:2025 risk - "Long-Lived Secrets" - and it's the most common breach precondition in identity incidents making headlines.

The numbers say the rest. In a typical enterprise Azure tenant, it's not unusual to find hundreds of service principals that haven't authenticated in 30+ days - each one a credential that continues to hold permissions nobody is actively using. CSA's 2024 NHI survey called service-account management the single most challenging identity problem reported by 32% of orgs. And cleanup isn't optional anymore: PCI-DSS 4.0 requirements (mandatory March 2025) explicitly require periodic review of service-account access.

What makes this stubborn is that "dormant" means different things in different apps. A 60-day-unused Snowflake service user is suspicious. A 60-day-unused IAM role for a quarterly batch job is normal. A 60-day-unused OAuth app with sensitive scope is dangerous. Native per-app reports stop at the app boundary - they don't know the IAM role's only consumer was an EC2 instance terminated last year, or that the OAuth app's consenter has left the company. Cross-app context is what makes "dormant" actually mean dormant. Without it, you're guessing.

What Oleria delivers

Oleria's Dormant NHI Detection and Decommissioning capability gives you a cross-app, continuously updated dormancy queue — with the dependency context you need to act safely, not blindly.

Cross-app dormancy in one query - no per-app scripting.

Last-used signal normalized across every connected app. One threshold or per-app thresholds, your call.

Safe-decommission context so you act with confidence, not blindly.

Each dormant NHI shows last consumer, last resource accessed, dependent applications, and seasonal patterns before you pull the trigger.

Per-app, per-NHI-type thresholds you control.

60 days for Snowflake service users, 90 days for AWS access keys, 30 days for OAuth apps with sensitive scope. App-aware defaults that eliminate false positives.

Decommission audit trail with rollback - so cleanup doesn't create production in

Every action logs context, reviewer, and rollback window. Pull the audit trail for your auditor in one click.

How it works

Connect - NHIs from every connected app, with last-used signal per NHI per consumer.
Ask - "NHIs not authenticated in 90+ days" - or your custom threshold.
Review - Sort by privilege, by app. Spot-check seasonal patterns before bulk action.
Act - Decommission, freeze, or queue for owner attestation. Rollback inside grace window.

What it looks like in your environment

You connect Entra, AWS, Snowflake, GitHub, and your other top apps. Within an hour, dormant inventory is 1,847 NHIs unused 90+ days. Of those, 47 hold admin scope and were last used in 2023. 312 are unowned. 89 are in non-prod environments that were decommissioned last year. The cloud team takes the AWS slice, the data team takes Snowflake, the platform team takes GitHub. Six weeks later, dormant count is 412 - down 78%. The recurring weekly hygiene cycle is 30 minutes of operator time. Auditor sees a quarterly evidence pack of decommission actions and rationale, not a fire drill.

What good looks like

Dormant NHI count: 1,847 → under 400 in one quarter - a 78% reduction in the first focused cleanup cycle.
Admin-scope dormant NHIs: identified and resolved - the highest-risk credentials prioritized and closed first.
Time to identify dormant NHIs: days of scripting → under 1 hour across every connected app simultaneously.
Decommission confidence: guesswork → dependency-aware - zero "wait, what was that for" surprises.
PCI-DSS 4.0 compliance: manual effort → quarterly evidence pack of decommission actions and rationale, audit-ready in one click.
Ongoing hygiene: ad hoc → weekly cycle under 1 hour of operator time. ---

Frequently Asked Questions

How do you decide an NHI is "dormant"?

"Dormant" means no successful authentication in your defined threshold window. Default thresholds are app-aware (60 days for SaaS service users, 90 days for cloud access keys, 30 days for sensitive-scope OAuth) but fully configurable. Your tenant, your thresholds.

Can I rollback a decommission?

Yes, within the configured grace period - default 7 days. After grace, decommission is permanent. The rollback window matters: it's the difference between "we cleaned up 1,800 NHIs" and "we cleaned up 1,800 NHIs and broke production for two of them, both rolled back the same day."

How is this different from per-app dormant-account reports?

Per-app reports stop at the app boundary. They don't know the IAM role's consumer was terminated. They don't know the OAuth app's consenter has left. Cross-app context makes the difference between "this looks dormant" and "this is dormant and safe to decommission."

Does this work for AI agents?

Yes. Copilot apps, Einstein integrations all surface in the same dormancy view. Same lifecycle treatment - agents are NHIs with a richer action stream, not a separate identity class needing a separate console.

What happens if a decommissioned NHI turns out to be needed after all?

If you're within the grace period (default 7 days), rollback is one click - the NHI is restored with its original permissions and the action is logged. After the grace window closes, decommission is permanent. If a service resurfaces after that, the right path is to re-provision from scratch with proper ownership assigned from day one - not to restore an unowned credential. The discipline of re-provisioning with an owner is the whole point.

Find and decommission dormant NHIs before they become a breach entry point

Outcome