Zero Trust Activity 1.1.1: User Inventory – Building Your Foundation

 In the world of Zero Trust, understanding exactly who (or what) is accessing your resources is paramount. It’s not just a best practice; it’s a fundamental requirement. This is where we dive into a seemingly simple, yet absolutely critical, piece of the Zero Trust architecture: Activity 1.1.1 – User Inventory. 

Think of it this way: you can’t secure what you don’t know exists. Before you can even begin to implement dynamic access controls, least privilege, or any of the other sophisticated mechanisms of Zero Trust, you need a definitive, constantly updated list of every single identity that might touch your environment. This isn’t just about your Active Directory users; it’s about service accounts, application-specific users, privileged accounts hiding in legacy systems, and everything in between. 

The goals of Activity 1.1.1 – User Inventory: 

1. Identify and inventory all user accounts: This means accounts managed centrally by your Identity Provider (IdP) or ICAM solution, and those living locally within individual applications and systems. 

2. Distinguish between regular and privileged accounts: Knowing which accounts have elevated permissions is crucial for future auditing and tighter controls. 

3. Uncover applications with independent user management: Identifying these silos is key to bringing them under central management or planning their eventual migration/decommissioning. 

4. Lay the groundwork for automation: Moving beyond manual spreadsheets to an automated, dynamic inventory process is the long-term objective. 

The desired outcomes are tangible: a clear picture of your “Identified Managed Regular Users,” “Identified Managed Privileged Users,” and of “Identified applications using their own user account management.” 

The cornerstone of many identity strategies is the Identity Provider.  

While the creation of a user inventory could begin as a manual process, an Identity Provider will ultimately be used. 

Centrally Manage the Accounts: The Identity Provider is designed to be the authoritative source or a key synchronizer for a large portion of your user base. It provides a centralized directory where you can create, manage the lifecycle of, and deprovision user accounts that are under its purview.  

Clear Identification of Managed Users: Within the IdP platform, you define users, assign them to groups, and associate them with applications.  

Handling Managed Privileged Accounts: The most mature IdP solutions provide Privileged Access Management, albeit, an organization could consider a specialized PAM tool.  

Enabling Automation for Managed Accounts: The IdP should have a robust API and integration ecosystem built for automation. Provisioning users to applications, updating attributes, and deprovisioning when necessary can all be automated, directly supporting the shift towards an “automated approach” for the identities it manages. 

Facilitating Integration-Based Discovery: While not a discovery tool in itself, the process of integrating applications with Okta for Single Sign-On (SSO) and lifecycle management forces the identification of which applications are being brought under central identity control. This indirectly helps in understanding a portion of your application landscape and where managed identities reside. 

The Critical Gaps: Where an IdP Needs Help for a Complete Inventory 

While IdPs will manage identities it knows about, it’s crucial to understand its limitations in the context of achieving a complete user inventory as required by Activity 1.1.1: 

Blind Spot for Local Accounts: IdPs will not automatically discover or inventory user accounts that are created and solely managed within individual applications or systems without any integration. These accounts are often in legacy systems or departmental applications (e.g., think home-grown applications) remain invisible to the IdP. Identifying these requires active discovery efforts beyond the IdP. The activity explicitly calls out inventorying accounts “locally on systems,” which is outside Okta’s core passive functionality. Discovering these independent identity silos requires discovery with your departments to identify and inventory this legacy applications.  It also includes network scanning, application discovery tools, or manual audits. 

Inventorying Unmanaged Privileged Accounts: Privileged accounts that exist directly on servers, databases, or in applications without being linked to the IdP or a separate PAM solution will need discovered. These unmanaged privileged accounts represent a high-risk attack vector. 

The Technical Buyer Takeaway: 

For technical buyers building a Zero Trust architecture, your IdP is a foundational element for managing known and managed identities. It is essential for centralizing identity governance and enabling automated processes for a significant portion of your user base. 

Keep in mind you will need to leverage other tools and processes – potentially including network scanners, application discovery tools, and manual audits – to identify those local accounts and applications with independent identity stores. 

And don’t treat Activity 1.1.1 as a one-time project. Your environment is constantly changing. Implementing a continuous discovery process and cultivating a “zero trust mindset” across your organization to prevent the creation of local accounts or workarounds from the centralized IdP are key to maintaining an accurate user inventory and strengthening your Zero Trust posture over time. 

FRC Recommendation: 

Based on its evolution into a comprehensive identity platform, we at FRC recommend positioning Okta as the central Identity Provider for your organization, specifically leveraging its core IdP functionalities alongside Okta Privileged Access for robust PAM capabilities. As the central IdP, Okta provides a unified source of truth for all user identities – from standard employees to those requiring elevated privileges – simplifying management and enforcing consistent authentication and access policies.  

By integrating Okta Privileged Access, you extend this centralized control to the critical realm of privileged accounts, enabling features like just-in-time access to infrastructure, secure credential vaulting, detailed session monitoring, and the ability to manage local accounts on servers.  

This combined approach with Okta as the central IdP and its dedicated PAM solution allows for a cohesive identity security posture, ensuring that all access, standard or privileged, is governed, monitored, and aligned with your Zero Trust principles. 

Pillar: User 

Capability: 1.1 User Inventory 

Activity: 1.1.1 User Inventory 

Phase: Target Level  

Predecessor(s): None 

Successor(s): None