Never used privileged user accounts are vulnerable to compromise as they often evade detection from defensive measures. Additionally, their potential default passwords make them prime targets for attackers.

A never used user is a user account created in Okta that never successfully authenticated to the Okta Dashboard for a certain number of days (90 days by default, customizable) since its creation.
They increase the attack surface for various reasons, such as:
<ul>
<li>A backdoor account allowing access to individuals who no longer require it, such as former employees or interns who never used this account.
</li>
<li>Continued use of the default password, thus exposing the account to a higher risk of compromise. For example, a <a href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a">CISA alert</a> reported that:
<blockquote>
campaigns have also targeted dormant accounts belonging to users who no longer work at a victim organization but whose accounts remain on the system
</blockquote>
and also that:
<blockquote>
Following an enforced password reset for all users during an incident, SVR actors have also been observed logging into inactive accounts and following instructions to reset the password. This has allowed the actor to regain access following incident response eviction activities.
</blockquote>
</li>
<li>Waste of resources such as licenses. Regular identification, deactivation, or removal of unnecessary users allow organizations to optimize resource allocation and save unnecessary costs.
</li>
</ul>
Also, consider the related IoE "Dormant User" which identifies all previously active users who have since become inactive.
The risk is higher for privileged users. See also the related IOE, "Never Used Non-Privileged User", for non-privileged users.
Note: The IOE relies on the <code>lastLogin</code> property, which has a <a href="https://support.okta.com/help/s/article/the-user-s-last-login-did-not-update?language=en_US">known limitation</a>: Okta only updates this value when a user accesses the Okta dashboard. As a result, SP-initiated authentications—such as when users access an application directly and are briefly redirected to Okta for authentication—do not update this property. Because of this, the IOE may report false positives for users who have never accessed the Okta dashboard but have successfully authenticated to applications. While Okta has <a href="https://support.okta.com/help/s/article/Howto-Properly-Identify-Inactive-Users-Using-Okta-Workflows-For-IdP-or-SP-Initiated-Login?language=en_US">documented a workaround</a>, it is not currently compatible with Tenable Identity Exposure. As a result, you must manually exclude these false positives.

Detections

Analytics

Never Used Privileged User

MEDIUM

Version 202507150942