Most organizations know they have identity risk. Very few can say where it is, how much of it there is, or which piece to fix first. The accounts are spread across dozens of SaaS applications, the permissions were granted years ago by people who have since left, and the only time anyone looks systematically is the week before an audit.
Identity risk management is the discipline of turning that fog into a ranked, actionable list. This guide covers what actually counts as identity risk, how to measure your identity attack surface, how to score exposure so you can prioritise, and how to move from a periodic assessment to continuous detection and remediation.
Identity risk management is the ongoing process of identifying every identity that can access your systems, understanding what each one can actually do, scoring the risk that access represents, and reducing it.
It is distinct from identity and access management. IAM is concerned with granting and authenticating access - getting the right people into the right systems. Identity risk management is concerned with the accumulated consequences of all those grants: the accounts nobody deactivated, the permissions nobody revoked, the service account with an API key that has not rotated in three years.
It differs from identity governance too, though the two overlap. Governance is about process and control - approvals, reviews, certifications, policy. Risk management is about measurement and prioritisation: given limited time, which findings matter most?
The practical distinction is that identity risk management produces a ranked list. That output is what makes it operationally useful, and it is what separates it from a compliance exercise.
A dormant account belongs to a real user who has stopped using it. An orphaned account has no valid owner at all - the employee left, the contractor's engagement ended, the team was reorganised. Both retain their permissions, neither is monitored, and nobody notices when one is used.
These are the highest-value findings in most first assessments because they are unambiguous. Nobody argues that a departed employee should keep their access. How to identify and mitigate orphaned accounts covers detection and remediation in detail, including the signals that distinguish a genuinely abandoned account from one used infrequently.
Permissions accumulate. Someone covers a colleague's responsibilities for a quarter and keeps the access. A role is cloned from an existing user who happened to be an administrator. A temporary elevation is never reversed.
The result is a population of users whose actual access substantially exceeds what their job requires. Each one expands the damage an attacker can do with a single compromised credential. Identifying overprivileged users means comparing granted entitlements against observed usage - and the gap is usually wider than teams expect.
Not every account in your organization was created through your identity provider. Employees sign up for tools directly, often with a corporate email and a password rather than SSO. Those identities are invisible to IAM, excluded from access reviews, and unaffected by offboarding.
This is the direct link between shadow IT and identity risk. Every undiscovered application is also a set of undiscovered identities. Shadow IT discovery and management covers finding the applications; the identities inside them are what make the finding urgent.
Controls decay. MFA is enforced on a tenant, then an exemption is granted for an integration and never removed. A password policy is tightened, but a legacy group is missed. SSO is mandated, yet local accounts remain active as a fallback.
Drift is insidious because the control still appears to be in place. The policy exists; it just no longer applies everywhere it should. The lifecycle of configuration drift: detection, remediation and prevention covers how to detect the gap between intended and actual configuration.
Service accounts, API keys, tokens, integration credentials and - increasingly - AI agents now often outnumber human accounts. They tend to hold broad permissions, they rarely have a clear owner, they are excluded from most access reviews, and their credentials frequently never expire.
They are also difficult to remediate safely, because revoking a service account's access can break production. That difficulty is precisely why they persist as risk. Managing identities for human and non-human users covers the governance side.
Your identity attack surface is the total set of identities, credentials and entitlements an attacker could use to reach something valuable. Measuring it is a discovery problem before it is a scoring problem.
A workable inventory answers four questions:
The fourth question is where most inventories break down, and it is the one that determines whether remediation is possible at all. A finding without an owner has nobody to action it, and it will still be on the list at the next review.
A list of thousands of findings is not actionable. Scoring turns it into a queue.
Three dimensions carry most of the weight:
Two practical notes. First, combinations matter more than individual signals. A dormant account is a finding; a dormant account with administrative privileges and no MFA is an incident waiting to happen. Scoring should multiply, not merely add.
Second, device posture belongs in the model. A user on a non-compliant device carries elevated risk in proportion to what they can reach - the same device is a minor issue for a read-only user and a serious one for an administrator. If your device data lives in an MDM platform and your identity data lives elsewhere, joining the two is one of the highest-value integrations available.
Most organizations begin with an identity risk assessment: a point-in-time review, usually driven by an audit or an incident. That is a reasonable start and a poor steady state.
The problem is decay. Access changes every day - people join, move and leave, integrations are added, permissions are granted for a deadline and never withdrawn. A quarterly assessment describes a state that stopped being accurate within weeks of completion.
Continuous identity risk management differs in three ways:
This is also the boundary between identity risk management and identity security posture management. Risk management is the discipline; ISPM is the continuous, tooled implementation of it. Check Identity security posture management (ISPM)] for more details.
You do not need a platform to begin. This sequence produces a defensible ranked list within a month.
Two guardrails. Do not disable service accounts without tracing dependencies first - that is how governance projects break production and lose organizational support. And record “why access was retained when it is retained”; those exceptions are your audit trail and your next review's starting point.
Josys discovers identities across your SaaS estate - including applications and accounts that were never provisioned through your identity provider - maps what each identity can reach, and scores the resulting risk continuously rather than at review time. Device signals, entitlement data and application usage sit in one model, so the combinations that matter are visible rather than split across tools.
You can see how discovery and governance work together on the identity security and risk page, or book a demo to walk through your own environment.
Identity risk management is the continuous practice of discovering every identity with access to your systems, understanding what each can do, scoring the resulting exposure, and remediating the highest-risk findings first. It differs from IAM, which grants and authenticates access, by focusing on the accumulated consequences of that access.
IAM is about provisioning and authentication - getting the right people into the right systems. Identity risk management measures what all that access adds up to and prioritises reducing it. An organization can run a well-managed IAM programme and still carry substantial identity risk, because IAM governs the front door while risk accumulates in accounts and permissions nobody revisits.
Inventory every identity across your identity provider, SaaS applications, cloud platforms and locally-created accounts, including non-human identities. For each, record what it can reach, when it was last used, whether its credential has rotated, and who owns it. The attack surface is the total reachable access; the ownership field is what makes it actionable.
An orphaned account has no valid owner - the employee left, the contractor's engagement ended, or the owning team was reorganised. It retains its original permissions, nobody monitors it, and no one notices if it is used. Orphaned accounts are typically the highest-value early findings because remediation is uncontroversial.
Point-in-time assessments decay quickly because access changes daily; a quarterly review is usually inaccurate within weeks. Quarterly is a reasonable minimum for a manual process, but the goal should be continuous discovery and scoring, with periodic reviews used to confirm the automated picture rather than to generate it.
Identity risk management is the discipline - discover, score, prioritise, remediate. Identity security posture management (ISPM) is the tooled, continuous implementation of it: platforms that maintain the inventory, update scores as signals change, and route remediation automatically. You can practise identity risk management manually; ISPM is what makes it sustainable at scale.
Service accounts, API keys, tokens and AI agents often outnumber human accounts, tend to hold broad permissions, frequently lack a clear owner, and usually have credentials that never expire. They are also risky to remediate because revoking access can break production systems - which is exactly why they accumulate. They belong in the same inventory and scoring model as human identities.
