Identity security maturity: a self-assessment

what identity security maturity means

Identity security maturity describes how consistently and systematically an organization manages the full life of digital access. At low maturity, access is granted on request, removed inconsistently, and never fully inventoried. At high maturity, every account has a known owner, access decisions follow a documented process, and periodic reviews confirm the environment matches the intent.

The practical difference is visibility and control. A mature identity environment can answer four questions reliably: who has access, to what, why, and whether that is still appropriate. Few organizations can answer all four without running a dedicated assessment.

Maturity does not require specific tooling at any given level. It requires consistent process and evidence that the process runs. A well-executed spreadsheet-based access review demonstrates more maturity than an expensive IGA platform that nobody uses correctly. This guide focuses on six dimensions that account for the access risk surface most relevant to mid-market organizations. Each is assessed independently. The lowest-scoring dimension is typically where the real risk sits.

the maturity model: four levels

These levels apply to each dimension separately. An organization can be Level 3 on MFA coverage and Level 1 on OAuth governance at the same time.

Level 1: Ad hoc. No formal process for this dimension. Actions are taken reactively when something goes wrong or someone asks. There is no inventory, no documentation, and no review cycle.

Level 2: Managed. Basic processes exist for the most visible scenarios. The main systems are covered, but coverage is incomplete. There is some documentation, but it is not maintained regularly. Actions depend on the right person being available and remembering to act.

Level 3: Defined. A documented, repeatable process covers the full scope of this dimension. Ownership is assigned. There is a review cadence and an evidence trail. Gaps can still exist, but they are visible and tracked rather than unknown.

Level 4: Measured. The process runs consistently, generates evidence, and is reviewed for effectiveness. Metrics exist and are acted on. The environment for this dimension can be described accurately at any point, not just after a manual survey.

Most mid-market organizations sit between Level 2 and Level 3 across these dimensions. The purpose of this assessment is to identify the dimensions where you are at Level 1 and treat them as P0 findings, ahead of any effort to advance higher-scoring dimensions further.

dimension 1: MFA coverage

MFA blocks more than 99.2% of account-compromise attacks (Microsoft). Partial deployment means partial protection.

What good looks like. MFA is enforced on every account in your directory, including admin accounts, service accounts where technically feasible, and all external access paths. The enforcement is required, not optional. Accounts cannot bypass MFA by using a legacy authentication protocol. New accounts are enrolled from day one.

What poor looks like. MFA is deployed on email and some SaaS tools, but not on VPN or internal systems. Admin accounts are inconsistently enrolled. Some users enrolled MFA but are not required to use it for every login. Accounts created before the MFA policy was introduced were never updated.

Self-assessment questions. Can you pull a list today of every account and see MFA enrollment status? Do any admin-level accounts have MFA not enrolled or not required? Does your VPN require MFA separately from your IdP login? Are there applications that accept direct logins, bypassing your IdP entirely? When were your admin accounts last verified for MFA status?

A single admin account without MFA enforced is a P0 finding regardless of how well everything else scores. The credential controls everything that admin can reach, and a password alone is the only barrier.

dimension 2: privileged access hygiene

Privileged access is any account that can change configurations, provision other accounts, access data beyond the standard user scope, or affect the security posture of a system.

What good looks like. Admin accounts are separated from daily-use accounts. Every privileged account has MFA enforced. The total list of privileged accounts across your environment is known and reviewed on a defined cadence. Admin actions are logged. Temporary elevated grants are time-bound and reviewed.

What poor looks like. Admins use their high-privilege accounts for daily work. Some people have admin access from a project months or years ago that was never removed. The full list of admin accounts across all systems has never been compiled. Audit logging exists in some systems and not others.

Self-assessment questions. Do you have a complete list of every account with admin or elevated privileges across your directory, cloud platforms, and major SaaS tools? Are any admin accounts used as daily-use accounts? How many people have admin access in your IdP, and how many are currently in a role that requires it? When did you last review whether a specific person still needs their admin grant? Are admin actions in critical systems logged and retained?

The risk with uncontrolled privileged access extends beyond the accounts themselves to the audit gap. When something goes wrong in a system with shared or undocumented admin access, the investigation has no trail to follow.

dimension 3: offboarding completeness

83% of employees admit they still have access to at least one account from a previous employer (Beyond Identity, 2022, self-reported). The average time to identify and contain a breach is 241 days (IBM). These two figures together describe what incomplete offboarding looks like in practice.

What good looks like. Offboarding triggers a documented process that covers every system, not only the primary directory. SaaS apps with direct logins are explicitly checked. OAuth grants the departing user authorized are revoked. API tokens or service accounts created by that person are identified and reassigned or rotated. A follow-up check runs 30 days later to confirm nothing was missed.

What poor looks like. Offboarding means closing the main directory account. SaaS tools that authenticate through SSO are assumed to be covered. Direct logins to tools not connected to SSO are not checked. OAuth grants are not specifically revoked. Tokens and service accounts associated with the departing employee are not identified.

Self-assessment questions. Does your offboarding checklist explicitly include SaaS tools not connected to SSO? Do you revoke OAuth grants when someone leaves, or assume that closing the directory account is enough? Do you identify and reassign API tokens or service accounts owned by departing employees? Do you have a post-offboarding check after 30 days? Can you answer, right now, whether a specific former employee from six months ago still has access to any system?

dimension 4: OAuth governance

OAuth grants are permissions that users give third-party applications to access data in your workspace. They accumulate continuously and rarely get revoked.

What good looks like. You have a current list of all active OAuth grants, with the application name, the scope of access, and the user who authorized it. Grants from inactive or departed accounts have been revoked. High-scope grants (full mailbox read, full file access, calendar write) are reviewed quarterly. New OAuth grants above a defined scope threshold go through an approval process before authorization.

What poor looks like. OAuth grants have never been audited as a distinct category. You have no complete list of what third-party applications currently have access to your Google Workspace, Microsoft 365, or Okta environment. Some employees who left had OAuth grants that were not specifically revoked. Several grants were created during product trials and have never been reviewed.

Self-assessment questions. Have you ever pulled a complete list of active OAuth grants from your IdP admin console? Do any grants belong to accounts that are no longer active? Are there grants with mailbox-read or full file-access scope from applications you no longer actively use? Does your organization have a process for reviewing or approving OAuth grants before users authorize them? When was the last time any OAuth grant was explicitly revoked by a deliberate policy decision?

OAuth governance sits at the intersection of SaaS security and identity. It is often the dimension with the largest backlog in environments that have not specifically assessed it.

dimension 5: shadow SaaS visibility

Shadow SaaS is any application in use that IT did not provision and has not reviewed. The risk is that those tools hold company data and have access paths your offboarding and access review processes do not cover. Employees adopt them because they are productive. The gap is that nobody has mapped what they can reach.

What good looks like. You have a current inventory of all SaaS applications in use, including those adopted by teams outside IT. New applications go through a lightweight review before users connect them to company accounts or load sensitive data into them. The inventory is updated when apps are added. Departed employees' accounts in non-SSO-connected apps are checked during offboarding.

What poor looks like. The official software list covers IT-provisioned tools. Departmental tools adopted by sales, marketing, or engineering over the past two years are not tracked. Users regularly sign up for new SaaS tools using their company email. Nobody has a full picture of what is in use.

Self-assessment questions. Does your IT team have visibility into SaaS applications adopted without an IT procurement step? Are there applications in use that store customer data or internal documents that IT did not provision? Do you include non-SSO-connected SaaS tools in your offboarding process? Have you checked which SaaS applications are visible in your IdP's connected apps list versus what is actually in use? When did you last update your official application inventory?

Shadow SaaS is a visibility problem, not a discipline problem. The solution is a process for discovery and lightweight governance, not a blanket prohibition.

dimension 6: AI tool exposure

AI tool adoption is moving faster than governance in most organizations. The dimension measures whether you know which AI tools are in use, what data is flowing into them, and whether there is a policy or process to govern that.

What good looks like. You have a current view of which AI tools employees are using, including browser extensions, standalone web tools, and integrations with existing platforms. There is a documented policy covering which tools are approved, what data can be used with them, and what is out of scope. AI tools that connect to company systems via OAuth or API have been reviewed. You know whether any tools are training on company data, and whether the appropriate agreements are in place.

What poor looks like. Individual employees use ChatGPT, Claude, Copilot, Gemini, and various AI browser extensions. Some use company email addresses to create accounts. There is no current inventory of which tools are in active use. There is no policy specifying what data can be put into AI tools. No one has reviewed whether any AI tool has an OAuth connection to company accounts.

Self-assessment questions. Do you have a list of AI tools currently in use? Does a policy exist specifying what company data can and cannot be used with external AI tools? Have you checked your IdP's connected apps list for AI tool OAuth grants? Are there AI browser extensions installed in browsers that also have access to company email or documents? Do you know which AI tools have default settings that include training on user inputs?

AI tool exposure is the dimension most organizations have not formally assessed. The absence of an assessment reflects a visibility gap, not an absence of risk.

how to score yourself

For each dimension, assign a level from the maturity model. Use the self-assessment questions to anchor your rating. If you cannot answer most of the questions for a given dimension, that dimension is Level 1. Where the answer is "we have a process but it doesn't cover everything," that is Level 2. Where a process covers the full scope and generates evidence, that is Level 3 or 4 depending on whether you also measure and review its effectiveness.

After scoring all six, look at the distribution. A single Level 1 dimension in a broadly Level 3 environment represents a meaningful risk concentration. The overall average is less important than the floor.

what to fix first: P0, P1, P2 thinking

Maturity assessments produce findings. The value is in the prioritization, not the list.

P0: fix immediately. Any admin account without MFA enforced. Any active account belonging to a person who left the organization. Any OAuth grant attached to a departed user's account that has not been explicitly revoked. P0 findings are live risks that can be acted on the same week. The action is specific (revoke this grant, enforce MFA on this account, disable this account) and the tooling required is whatever you already have.

P1: fix this quarter. MFA gaps on non-admin user accounts. Shadow SaaS applications storing sensitive data without governance. OAuth grants with high scope from applications no longer in use. Privileged accounts never specifically reviewed against current role requirements. Offboarding gaps where the process is documented but does not cover SaaS outside SSO. These require process design or coordination, not just a one-time action.

P2: schedule for the next review cycle. Dimensions where the process is partially defined and needs formalization. AI tool governance where usage exists but no policy does. OAuth grant review cadences that need to be established. Shadow SaaS discovery that needs to be run annually. P2 findings carry real risk and rank below P0 and P1 only because they require structural process work rather than a single discrete action.

A useful rule: if you cannot state clearly which person owns a finding and what specific action closes it, the finding is not well-defined yet. Good prioritization produces actionable items, not categories of concern.

how this maps to access reviews and frameworks

Identity security maturity and access reviews are related but distinct. Access reviews are the periodic process of certifying who should still have access to which systems. Maturity describes the system of controls within which access reviews are one component. An organization can run access reviews without strong maturity in the other dimensions: if MFA coverage is poor and OAuth grants are not inventoried, access reviews will certify access in the directory while the real risk sits in the dimensions the review did not cover.

SOC 2 addresses privileged access, MFA, and user access review across its logical access controls criteria (CC6.1 through CC6.3). ISO 27001:2022 includes controls on access management (Annex A, 5.15-5.18), authentication information (5.17), and access rights review (5.18). NIS2 requires covered entities to implement access control policies and demonstrate that access to critical systems is managed appropriately (Article 21). DORA requires financial entities to maintain ICT access controls that extend to privileged access management and periodic review (Article 9). Maturity in these dimensions does not produce a certification. It produces the evidence and the underlying state that certifications and audits check for.

common patterns

These show up frequently across assessments and are worth checking specifically.

MFA at Level 3 on users, Level 1 on admins. MFA rollout often covers standard users while admin accounts are deferred because of perceived operational complexity. The result is that the highest-privilege accounts are also the least protected.

Offboarding Level 3 for the directory, Level 1 for everything else. The formal checklist closes the IdP account and the laptop. SaaS apps with direct logins, OAuth grants, and service accounts the departing user created are not in the process. The gap is not visible because offboarding appears to complete normally.

OAuth grant backlog that was never cleared. Organizations running Google Workspace or Microsoft 365 for several years typically have hundreds of active OAuth grants, many from applications no longer in use. When pulled and reviewed for the first time, a substantial portion belong to inactive accounts or hold broader scope than the application's function requires.

Shadow SaaS and AI occupying the same governance gap. In many organizations, neither has been formally assessed. Both are treated as team-level decisions that IT is not expected to govern. The data flows from both are typically neither classified nor tracked.

Privileged access spread without intent. Admin grants in SaaS tools are frequently created during migrations, integrations, or onboarding periods, and never reviewed afterward. The total count of accounts with some form of elevated access is typically larger than the security or IT team estimates.