Field notes on modern identity

Leadership wants agents. The identity team already knows what those agents are going to inherit.

Most of us have spent years carrying an environment that mostly works. Access granted for a reason nobody wrote down. Roles and groups named after teams that no longer exist, or people who left years ago. A service account holding something up that no one wants to touch. None of it was ever fine. It was survivable, because it moved at human speed and there was usually time to catch it before it mattered.

Agents take that time away.

AI did not create any of this. It shortens the distance between a weak decision and its consequence. Something that sat unnoticed for a year can surface in an afternoon.

That is the idea Series 3 is built on. AI does not fix identity. It exposes it.

The story that opens my book is about an access form that could only grant access and never take it away. Series 3 picks up from there.

Series 1 laid out the model. Series 2 was about putting it in place. This one is about leading it. In it I share stories from the field about where identity gives way: access that never leaves, the accounts nobody hired, the audit everyone passed, the assistant working under someone else's name, and what leaders can do before AI finds those gaps first.

If you have spent years carrying one of those environments, this series is for you.

Related

• The story that opens the book: https://www.linkedin.com/feed/update/urn:li:activity:7509971148944719872/
• Series 1 and 2: linkedin.com/in/beckysandberg/details/projects/

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

I have watched this happen more than once, in more than one organization. The details here are blended. The pattern is not.

A contractor starts on Monday. They show up ready to work.

Someone put in a request for network access, so they can get on the network. That is as far as they get.

The work lives in three systems, and each one needs its own request. And a few days in, someone discovers a fifth: the virtual desktop that is the only way into those systems.

Who submits them is its own problem. Sometimes it is the manager. Often it is whoever is closest: a teammate, someone from the consulting firm, another person, or the contractor themselves. The access has one name on the team and a different one in the request catalog. And when a request stalls, who do you even ask?

Then the waiting starts. Approvals rarely come back the same day, and each approved request then lands in an admin queue, where a three-business-day turnaround is common unless provisioning is automated. Five requests finish at five different times. Specialized access, with extra approvals, security reviews, or a license someone has to buy, takes longer still.

When the last one finally clears, the contractor asks the question nobody planned for.

"How do I actually log in?"

In between, they shadowed a teammate, sat in on meetings, and read whatever they could reach. And they billed every hour, because they were there and ready.

At $100 an hour, two weeks of that is $8,000. Three weeks is $12,000.

And the invoice is only the part you can see. It does not count the hours spent by the requestor figuring out forms, the approvers reviewing each one, the admin teams working each ticket, and everyone escalating along the way. The project planned around their start date slips just as far, and everything behind it moves too.

Nobody did anything wrong. The process had been built one system at a time, and nobody had ever walked through it as the person starting on Monday.

Most of what this contractor needed could have been known before they started. People doing the same work tend to need the same access. When that is defined ahead of time, many of these requests never need to exist. That is what access roles are supposed to do. Why they often don't is Series 3 Post 7, Why RBAC Fails.

Leading identity means walking it that way. Count the requests, the people who touched them, the days, and the hours someone spent waiting to do the job you hired them for.

Five requests is not the highest number I have seen. I suspect someone reading this has a bigger one.

Related

• Series 1 Post 10: https://www.linkedin.com/feed/update/urn:li:activity:7436803027178614784/

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

Someone in finance moves to a new job and keeps their old access for a while to help their backfill. A year later, two people still have it.

It starts as a reasonable request. Nobody wants the new person stuck, and the one who knows the work best is right there.

The trouble is that "for a while" has no end date. Nobody circles back. The old access stops being used, but it does not stop working. A year later, two people hold the old job's access: the one doing the job and the one who left it.

In finance, that can matter. The person who moved may now be able to do two things that were deliberately kept apart. In my book I call this drift. An AI assistant working with that person's access would find it in an afternoon.

Moves tend to be the lifecycle event programs handle worst, because nothing forces the question. The new access gets done. The old access just stays.

Here is where I would start.

Grant transition access as its own request, with an end date and an owner.

Decide what counts as a move. It is often a combination, like a new job title in a different department. If access roles are granted from attributes, a change to those attributes is a move.

Make every move trigger a review of everything the person holds. Removing the old access role does not touch anything they requested on their own.

For people who have moved since their last review, a one-time certification campaign is often the easiest way to catch what was left behind.

It usually starts with someone trying to help.

Related

• Series 1 Post 6: https://www.linkedin.com/feed/update/urn:li:activity:7428120801469534208/
• Series 3 Post 1: https://www.linkedin.com/feed/update/urn:li:activity:7511810753725865985/

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

Some of the most loyal users in a system are people who no longer work there.

I found that out while working with system administrators to understand how they provisioned and removed access. We were drafting an identity standard, and I wanted it to reflect how the work actually happened.

We walked through their processes one system at a time and found gaps along the way. Then I asked for access to the systems themselves, and for exports of their users.

The conversations told me how the process was supposed to work. The exports told me how it did.

We were paying for licenses for people who had left the company, some of them long gone. And people who had been terminated still had active access in those systems, months later.

Nobody was hiding anything. Removal depended on someone remembering to do it, in each system, every time someone left. When access is being granted, someone is waiting on the other end and asking where it is. When someone leaves, nobody is waiting, so nobody asks.

That gap has costs that do not show up anywhere obvious. Licenses renewing for people who are gone. Accounts that still work for someone who no longer works there. Audit findings when someone finally looks. Hours of cleanup, system by system, just to find out who is still in there. And an account that still works is an account something can still use, whether that is a person, a script, or an AI tool that finds it first.

It is the same problem as joining, running in reverse. Access arrives one request at a time, and it leaves the same way, if it leaves at all.

This is where leading identity gets practical. Do not stop at the process description. Ask for the export, and compare who is in the system with who still works here. The person leading identity is usually the one who has to ask, because nobody else will.

Related

• Series 2 Post 12: https://www.linkedin.com/feed/update/urn:li:activity:7463610436785975297/
• Series 3 Post 1, The Cost of Waiting for Access
• Series 3 Post 2, The Access That Follows You

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

Joining, moving, and leaving all follow people. Nonhuman accounts do none of that. Nobody hires a service account. It never changes jobs. It never has a last day. It just keeps running.

At one organization, a directory cleanup meant going through every nonhuman account to figure out what access each one actually needed.

We started with the accounts that held the highest-risk access. That was the right call. It still took several months.

The access varied widely. Some accounts had very little. Others had far more than anyone could explain. Every one had to be looked at on its own.

Figuring out who owned each account was often harder than figuring out what it could do. The person who created it had moved on, or the team that relied on it had changed. An account with no owner is an account nobody can make a decision about.

And many of those accounts belonged to vendor products. That meant going back to the vendor, asking exactly what their product needed, and working toward an answer specific enough to scope.

This is what happens when accounts are created to solve a problem in the moment and never given an owner, a purpose, or an end.

Here is how I would lead it again.

Start with the highest-risk access, and tell leadership up front that it will take months.

Treat ownership as the first deliverable. Until someone owns an account, nobody can make a real decision about its access.

Bring vendors in early, and make "what exactly does your product need" part of how you buy and renew.

And stop the next backlog from forming. Every new nonhuman account gets a named owner, a stated purpose, and scoped access the day it is created.

This was before AI agents started showing up in the same directories. That part gets its own post.

Related

• Series 1 Post 5: https://www.linkedin.com/feed/update/urn:li:activity:7426671282089422849/
• Series 2 Post 13: https://www.linkedin.com/feed/update/urn:li:activity:7465023946904506369/
• Series 3 Post 3, The Cost of Access That Never Leaves

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

I have watched a clean audit miss almost everything, cycle after cycle.

The directory had grown to tens of thousands of groups. Every one of them was an entitlement, a way of granting access to something. Most had no description and no owner anyone could name. For many of them, there was nobody left to ask.

A small set of those groups was in scope for audit, so those were the groups that got reviewed. Same list, every cycle. The reviews closed on time. The audit came back clean.

Everything outside that list still granted access, and nobody could say to whom or why. The same thing happens with application roles and permissions, anywhere only part of the access is ever reviewed. None of it was anyone's job to look at, because none of it was going to be tested. It drifted there, one reasonable decision at a time.

This is how attention works in a lot of identity programs. The audit scope draws a line, and the line becomes the program. A clean audit tells you the list was reviewed. Whether it was the right list is a different question.

AI does not see that line. An AI tool connected with broad access uses whatever it can reach, in scope or not.

Auditors test what is in scope. Deciding what deserves attention belongs to the person leading identity. You do not have to review everything at once.

Find the access outside audit scope that reaches your most sensitive systems, and give it an owner and a review of its own.

Let what access reaches set how often it gets reviewed, whether or not an auditor will ever ask about it.

Before you connect an AI tool, limit its access to what its job needs.

I would rather choose what gets reviewed than let the audit list choose for me.

Related

• Series 1 Post 8: https://www.linkedin.com/feed/update/urn:li:activity:7432469453767966721/
• Series 3 Post 4, The Accounts Nobody Hired

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

A manager opens an access review. It lists their team and every entitlement each person holds, by the name the system uses. They are supposed to decide whether each one is still needed. But they cannot tell what most of these entitlements actually let a person do.

So they ask the entitlement owner. The owner does not know either.

This gets harder the moment you look beyond the audit list, which was the subject of Series 3 Post 5, Tens of Thousands of Entitlements and the Few Anyone Reviewed. Everything you find has to be reviewed by someone.

This is one of the hardest problems in identity, and one of the most common. An entitlement was created years ago for a reason nobody wrote down. It has been granted, copied, and approved so many times that it looks legitimate. But nobody can say what it does, and you cannot make a real decision about access nobody can explain.

So the reviewer approves, because removing something you do not understand feels riskier than keeping it. The campaign closes on time. Nothing changes.

AI can help here. It can read what an entitlement touches and how people actually use it, and give you a good first guess. But a guess is not an answer until someone who owns it confirms it.

From there, there are a few honest ways out, and none of them are quick.

Start with the entitlements nobody has used in months. They are the safest to remove and the quickest to learn from.

Sometimes you remove the entitlement, with the people who hold it forewarned and a way to put it back, and see what they can no longer do. If something breaks, you learn what it was for.

Sometimes you build a new, clean entitlement that grants only what you know is needed, move people onto it, and retire the old one.

And sometimes you accept the risk for now, write it down with an owner, and make a plan to figure it out.

Those choices belong to the person leading identity. Reviewers and owners can only work with what they know. A leader decides which path each unexplained entitlement takes, makes sure someone owns the answer, and stops treating an approval as proof that anyone understood what was approved.

Give reviewers an answer besides approve or revoke. "I don't know what this is" should be a real choice that sends the item to the owner or the identity team. And show reviewers a plain-language description instead of the system name.

An entitlement nobody can explain is still granting access every day. I would rather find out what it does than keep approving it.

Related

• Series 1 Post 8: https://www.linkedin.com/feed/update/urn:li:activity:7432469453767966721/
• Series 3 Post 5, Tens of Thousands of Entitlements and the Few Anyone Reviewed

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

I have seen access roles built one to one with entitlements, and access roles named after the person they were built for. Neither one helps a reviewer decide anything.

When I say role here, I mean an access role: a defined bundle of entitlements. A job role is what someone does for a living. Mixing the two up is where a lot of this goes wrong.

A program decides to build access roles. Someone pulls what people in each job currently have, finds the common access, and calls it a role. But what people currently have includes years of exceptions, "same as" copies, and access nobody removed. Mining it just gives the mess a name.

Then the access roles multiply. A role for each team, then each variation, then each person who needed one more thing. When they are built one to one with entitlements, every new entitlement means another role to create, maintain, and review.

In my experience, RBAC fails because keeping access roles accurate is nobody's job. Most programs treat them as a project: build, launch, move on. RBAC only works when it is run every day like any other process. That is a leadership decision.

You do not need an access role for every job. Start with jobs many people share and jobs with high turnover.

Give every access role an owner who can say what it is for, reviews what is inside it on a schedule, and is accountable when it drifts.

Decide on purpose which access people should simply have because of their job, and which should still be requested and approved. Making everything automatic over-grants on day one. Making everything a request puts every new hire through a week of requests.

Use role mining, and AI, as evidence. They are good at showing you what people have. Only the business can tell you what people should have.

Watch how much access is granted outside of roles. If it keeps growing, the roles are falling behind.

And retire access roles when the work they were built for goes away.

Done that way, the contractor from Post 1 gets most of what they need on day one, and a backfill gets the job's access instead of the last person's history.

Related

• Series 1 Post 8: https://lnkd.in/gSWs-Pdn
• Series 3 Post 1: https://lnkd.in/gNDE3ytD
• Series 3 Post 2: https://lnkd.in/g6hmc4HQ
• Series 3 Post 6: https://lnkd.in/gVBxpdEk

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership

A lot of IAM teams have pieces of a program in place.

They have tools.

They have workflows.

They have integrations.

They have pockets of ownership and governance that are working well.

What helps implementation move forward is a reliable view of the environment those pieces are meant to support.

You can't govern what you can't see, and you can't improve what you haven't mapped.

Identity is spread across more places than the official architecture suggests. HR and contractor systems, directories, IGA, PAM, cloud IAM, local access models, workload identities, external identity stores, shared data platforms, and legacy integrations all shape how identity behaves.

This is where it helps to separate three things:

IAM as a team leads and coordinates the work.

IAM as a program provides the tools, processes, and services.

IAM as a model explains how identity actually behaves across the environment.

The IAM team will not own every system.

The IAM program may not govern every access path.

But the IAM model still has to account for any system or platform that grants or enforces access for human or nonhuman identities.

Once you take that broader view, the next step is understanding what the environment actually contains.

A reliable inventory is not just a list of applications. It is a map of identity-bearing systems, the data they consume, how identities authenticate into them, what access they grant or enforce, who owns them, and what risk they create.

A CMDB can help, but in many environments it is incomplete, outdated, or missing the systems that create the most identity risk. That does not stop the work. It means the inventory becomes part of the implementation effort.

Start by getting clear on:

Which applications, systems, directories, platforms, and identity stores grant or enforce access?

What source data lands in each system, and what does it drive there?

How do identities authenticate into each system, and what controls apply there?

Who is the business owner, technical owner, and access owner for each system?

How is the access risk of each system ranked?

Which systems are governed, and which still need to be brought onto the roadmap?

Why it matters

Implementation starts by gathering the right data, understanding the environment, prioritizing the systems and risks that matter most, and building the roadmap from there.

Any progress here is good progress, especially when the work is moving in a shared direction.

What is the hardest part of your identity landscape to get clear visibility into?

Read on LinkedIn

Once the environment is visible, the next question is straightforward:

Who actually has to work together to make the model hold?

This is where identity implementation becomes very different from identity architecture.

IAM can lead and coordinate the work, but it cannot carry the model alone. Identity truth, lifecycle inputs, authorization logic, privilege decisions, exceptions, and measurement all sit across different teams. When those teams are not aligned, the program may still exist, but the model underneath it stays weak.

Everyone may own a part of the work, but that does not mean anyone is holding the system together end-to-end.

Shared responsibility is not just a principle. It is an implementation requirement.

Identity implementation depends on participation from:

HR and workforce source owners

Vendor and procurement teams

Managers and business owners

Application owners and engineering teams

Cloud and platform teams

Security, audit, risk, and governance functions

If IAM is becoming the control plane, cybersecurity, IT, cloud, IAM, and application teams cannot keep operating as disconnected silos.

That shared model has to hold across workforce, nonhuman, privileged, external, cloud, application, and data access scenarios, not just the parts traditionally labeled IAM.

Start by getting clear on:

Which teams create, govern, consume, or enforce identity outcomes?

Which decisions belong to IAM, and which belong elsewhere?

Where does the IAM team need partnership, not ownership?

Which governance forums already exist, and who is missing from them?

Where does confusion about decision rights slow the work down?

Application onboarding is one example. IAM may not own the application, but it still needs enough involvement to understand authentication, provisioning, authorization, ownership, and risk before that system becomes another unmanaged access path.

Why it matters

When shared buy-in is weak, implementation slows, ownership gaps widen, and governance gets harder to sustain. The issue is rarely effort. It is alignment around the model.

The model becomes real when the teams around it start working differently.

Where does collaboration usually come under the most strain in your identity work?

Read on LinkedIn

Now that we've named who needs to be involved, the next question is what they are actually working from.

Teams use the words policy, standards, guidelines, and procedures as if they mean the same thing. They do not. That difference matters a lot more in implementation than most teams realize.

One of the most common gaps is that operational and IT teams are often not aware of the policy or standards that apply to them. They may not use the word guideline at all. What they usually have, if anything, is an SOP or runbook. If those operational documents are disconnected from policy and standards, the work may still get done, but the model underneath it starts to drift.

This matters across identity types and environments. If governance is inconsistent in one part of the model, it rarely stays there.

Start by getting clear on:

What belongs in policy versus standards?

Which identity domains already have standards, and which still depend on tribal knowledge?

Where are guidelines needed because teams are making judgment calls without shared direction?

Which procedures, SOPs, or runbooks reflect how the work is actually done today?

Which of those are disconnected from current policy or standards?

Who owns each layer, and who uses it to make decisions?

For example, in privileged access:

Policy: Privileged access must be approved, time-bound, and monitored.

Standard: Privileged access must use MFA, named accounts, and JIT elevation where supported.

Guideline: Use standing privilege only where operationally necessary and document compensating controls.

Procedure: Submit elevation request, obtain approval, activate access, log activity, and remove access at the end of the approved window.

You do not have to fix every governance document at once. But teams do need a shared foundation they can actually work from.

Why it matters

When these governance layers work together, implementation becomes easier to sustain across systems, identity types, and access paths.

Policy, standards, guidelines, and procedures are not interchangeable. The clearer each layer is, the easier the model is to implement consistently.

Where do you see the most confusion today: policy, standards, guidelines, procedures, or exceptions?

Read on LinkedIn

Once the environment is mapped and the partner landscape is visible, the next question becomes clearer:

Where is the operating model under the most strain?

In many environments, the first challenge is not tooling. It is one or more weak operating conditions that keep showing up in different forms.

Ownership may be vague. Identity truth may be unreliable. Lifecycle may not reflect organizational reality. Entitlements may lack purpose. Authorization logic may be governed at the wrong layer. Privilege may be convenience-based. Drift may be hard to see early.

Those conditions usually show up later as:

broken reviews

access sprawl

repeated manual correction

unmanaged nonhuman identities

privilege creep

recurring exceptions

Start with diagnosis.

Identify the weakest operating condition before selecting the next improvement step.

Separate root causes from downstream symptoms.

Prioritize conditions that destabilize multiple parts of the model.

Focus first on weaknesses that make the rest of the system harder to predict.

Avoid starting with the loudest issue if it is not the structural one.

Why it matters

Starting with the weakest condition reduces repeat correction and keeps symptoms from becoming design.

Measure:

• identity truth accuracy
• lifecycle alignment
• access purpose alignment
• privilege containment
• authentication strength
• operational reliability
• recurring exceptions tied to structural operating model weakness
• identity processes requiring repeated manual correction
• Validate:

Ask which weakness creates the most downstream instability.

Ask which issues keep repeating across tools or processes.

Ask whether teams are solving symptoms or improving root conditions.

Compare observed issues to the operating condition behind them.

The work usually goes better when diagnosis comes before deployment.

In the environments you've seen, where does the operating model usually weaken first: ownership, identity truth, lifecycle, access structure, privilege discipline, authentication, nonhuman identity governance, or operational coordination?

Post to Identity & Access Management Specialists Group

Request for Perspective

Identity practitioners and leaders, I want your perspective on something we all wrestle with.

If you work in Identity and Access Management long enough, you start to see the same patterns repeat. Tools change. Vendors change. Buzzwords definitely change. But the operating model problems stay stubbornly the same.

Over the past few months, I've been writing a multi-series body of work on the Modern Identity Operating Model.

Series 1 covers the foundations.

Series 2 focuses on implementation.

Series 3 is now being outlined and looks ahead to what identity must become in an AI-mediated, appless, autonomous world.

Series 2 is structured as a 16-post sequence, published twice a week. Post 5 went live this morning, and the conversations so far have been incredibly valuable. One theme I keep hearing is that the series needs to go deeper on how agentic AI will reshape IAM. I agree. The operating model should hold no matter what we throw at it, including the rapid rise of agentic AI and the explosion of workload identities that comes with it. If the model only works when the environment is stable, it is not a model. It is a diagram. IAM needs something sturdier than that.

I am also considering expanding this work into a larger publication, and before I take that step, I want to hear from the people who live this work every day. This group has some of the strongest practitioners in the industry, and your insight would help shape where this goes next.

📘 Series 1: The Modern Identity Operating Model

Introduction to the series:

https://lnkd.in/du9V66Jk

Links to all posts in Series 1, all published posts in Series 2, and the full outline for Series 2 are in the comments.

If you read even one post, I would appreciate your thoughts. What resonates. What you disagree with. What you have seen in the field that others should know. IAM only gets better when practitioners share what actually works.

Looking forward to the discussion.

hashtag#IAM hashtag#IdentityManagement hashtag#IGA hashtag#ModernIdentity hashtag#OperatingModel hashtag#CyberSecurity hashtag#IdentityGovernance hashtag#AccessManagement hashtag#AgenticAI hashtag#AIGovernance hashtag#PractitionerCommunity

Read on LinkedIn

Once weak operating conditions are visible, the next step is to assess how mature the operating model actually is today.

That does not mean starting with a tool scorecard. It means assessing each critical system against the IAM standards, the intended operating model, and the operating conditions that determine whether identity behaves predictably.

A lot of identity maturity conversations still start with tooling:

what is deployed

what is integrated

what controls exist

That matters, but it still leaves out the question that matters most:

Does identity behave predictably?

In practice, maturity is less about capability count and more about how reliably the system produces the outcomes the organization expects. Mature identity environments are easier to govern because ownership is clearer, identity truth is stronger, and lifecycle, access, privilege, and authentication behave more consistently under change.

Assess maturity system by system, starting with the critical systems identified in the inventory.

For example, a critical application may already be integrated to IGA, but if its entitlements have no clear purpose, approvals route to the wrong owner, or access is still adjusted manually, the maturity gap is not the connector. It is the governance, ownership, and operating discipline around the application.

This is also a good point to talk with GRC, Internal Audit, or equivalent oversight teams to understand where concerns are already surfacing and which gaps keep showing up in reviews or audits.

Start by getting clear on:

Is ownership clear and exercised?

Does source-of-truth integrity hold across identity types?

Does lifecycle reflect organizational reality?

Do roles and entitlements have purpose?

Is authorization governed where it actually lives?

Is privilege intentional and contained?

Do authentication methods and policies reflect actual risk, identity state, and access context?

Which critical systems should be assessed first based on risk, business dependency, and current instability?

Why it matters

A predictability-based maturity view helps identify the gaps that should shape the roadmap first.

Measure:

• identity truth accuracy
• lifecycle alignment
• access purpose alignment
• privilege containment
• authentication strength
• operational reliability
• certification effectiveness
• integration stability

A mature identity operating model is one the organization can trust to behave consistently under change.

Would a predictability-based maturity model be more useful than one based mostly on tool adoption?

Read on LinkedIn

Identity Truth First: Source of Truth, Data, and Classification

One of the key questions when building the roadmap is this:

Can the organization actually trust its identity truth?

Implementation depends on it. When systems hold different versions of the same identity and no one defined which attributes come from where, downstream decisions start losing reliability. It also gets harder when data owners do not know where their data is used downstream or what breaks when that data is wrong or late.

Source of truth is rarely a single system. HR may anchor workforce identity, but contractor, external, and nonhuman identities often originate elsewhere. The work is deciding which attributes are authoritative, how identity types are classified, and how updates should propagate.

Identity truth matters when authoritative source data lands where it needs to, in the form downstream systems expect. Strong data models support lifecycle, provisioning, approvals, and authorization.

This is why partner relationships matter. When source data is maintained well, downstream teams can rely on it. Improving identity truth often means helping source owners strengthen the upstream process.

Classification determines how identity is governed. If identity types are unclear, lifecycle rules, approvals, access models, and policy decisions become inconsistent.

Start by getting clear on:

Which authoritative source owns each core attribute for each identity type?

How are workforce, contractor, external, privileged, and nonhuman identities classified?

What source data lands downstream, and what does it drive?

Which attributes drive provisioning, approvals, authorization, and lifecycle behavior?

Where is downstream logic compensating for weak identity truth?

Which critical systems are showing strain from incomplete, stale, or inconsistent source data?

Why it matters

Clear identity truth improves lifecycle accuracy, access consistency, approval quality, and the predictability of downstream decisions.

Measure:

• authoritative source coverage
• identity-type source accuracy
• attribute completeness rate
• attribute freshness rate
• source-of-truth alignment rate
• conflicting attributes across systems
• manual downstream corrections tied to source data quality

Identity truth does not become reliable because a source system exists. It becomes reliable when the organization clearly defines what that source represents and how the rest of the environment should behave because of it.

Where does source-of-truth confusion create the most friction in your environment today?

Read on LinkedIn

The first six posts covered the foundations. Now the path must be built.

Before sequencing a single component, most programs skip a governing question: What does the right implementation path look like for this organization?

Many default to a framework, a vendor roadmap, or what worked somewhere else. None of those account for the organization you actually have.

Many factors shape the path. Two are rarely named: risk appetite and change appetite. They are not the same thing, and treating them as if they are leads to implementation designs that do not survive contact with the organization.

Risk appetite is how much unresolved identity risk the organization will carry while the program matures. It determines enforcement pace, how long you operate in identify but do not block mode, and how quickly assessment turns to action. Assumed risk appetite is not a strategy. It is drift. Someone has to name it.

Change appetite is how much disruption the organization can absorb and at what pace. It accounts for competing initiatives, stakeholder friction, and available organizational energy. Low change appetite demands a different sequence. Not slower, but more deliberate.

Together they govern sequence, depth, enforcement pace, and scope. Starting with a limited set of functions across a limited selection of applications, then expanding as appetite allows, is not a compromise. It is a design decision.

Think of this as a decision matrix. Appetite inputs, stakeholder positions, competing priorities, and leadership signals feed a structured case for what to tackle in what order. Trusted relationships make that analysis accurate. Without them, you get the answer people think you want, not the one that reflects reality. Sometimes leadership names the problem directly. That signal shapes the path too.

Once the case is built, it has to be sold. Stakeholder analysis, sequencing rationale, and why this path fits the organization are all part of that work. Executives will have other thoughts. Sometimes the sequencing shifts. That is part of the process.

Start by getting clear on:

• Has risk appetite been named, or is it being assumed?

• What is competing for change capacity right now?

• Which components demand faster action because of risk?

• Where are temporary controls needed while permanent ones are built?

• Who has authority to make these decisions, and are they engaged?

Where you begin is a decision, not a default.

❓What is the harder part: building the case for the sequencing, or navigating the organizational dynamics that shape it?

Read on LinkedIn

Most identity programs are not behind because the work is hard. They are behind because too much work is in progress at the same time and none of it is operational.

Wave based implementation is not a project management preference. It is a governance discipline. Each wave has a defined scope, a dependency chain, and a clear definition of what operational looks like when the wave closes. Without that discipline, implementation becomes a permanent state of partial completion. Tools are deployed, processes are half built, and capabilities exist in slides but not in practice.

Identity work makes this even more important. Lifecycle, access governance, privilege, and cloud entitlements all depend on each other. Waves keep the program focused on what must be true before the next capability can run.

Three factors govern wave design.

Dependency. Some capabilities work better when foundations are in place. You can govern entitlements without clean identity data, but the results drift and the work repeats. You can run access certification without defined roles, but the outcomes are weak. Wave sequencing follows the order that produces durable results.

Risk. Where the exposure is highest is where implementation often needs to begin. High risk populations, high risk systems, and high risk access patterns shape the early waves.

Readiness. Not every part of the organization can move at the same pace. Wave design accounts for where governance structures, ownership, and change capacity exist to sustain what gets built. Sometimes the right starting point is the part of the organization that is ready to move. Early wins create momentum that makes the harder waves possible.

A wave is not complete when the technology is deployed. It is complete when the operating model is running in scope. The process executes, governance is active, and measurement confirms it is working.

The most common failure in wave based implementation is not finishing waves. The next priority arrives, scope expands, and nothing reaches sustained operation. Many programs have work in progress from years ago that no one has declared done.

Define the wave. Close the wave. Then expand. Closing a wave creates a moment to celebrate what is working and capture what needs to improve before the next one begins.

Measure:

• Waves defined with explicit scope and exit criteria
• Capabilities confirmed operational before the next wave begins
• Open initiatives with no declared completion date

❓How many open identity initiatives have never been declared done?

hashtag#IdentityManagement hashtag#IAM hashtag#IdentityGovernance hashtag#IdentityOperatingModel hashtag#Implementation

Read on LinkedIn

As organizations move from understanding their risk and change appetite into implementing the modern identity operating model, clarity becomes essential. Teams may use different tools, patterns, and identity stacks, and that is expected. What matters is that the model's core jobs are defined so every identity type can move through the environment consistently.

The operating model depends on four distinct jobs: source, registry, governance, and enforcement. Each identity type, including nonhuman identities, may have its own version of each job. The model still works as long as the jobs are clear.

Source establishes identity truth. This is where authoritative attributes and lifecycle signals originate.

A registry tracks identity across sources. It correlates identities, tracks identity types, and provides a consistent view of identity records, even when separate registries exist for different identity types.

Governance determines what should happen. Access decisions, approvals, lifecycle impact, review, and accountability live here. An identity governance platform may perform much of this work. The important point is not the product, but which job it performs in the model.

Enforcement is where decisions become technically real. Accounts, attributes, groups, and downstream identity representations are applied here. Directories, cloud identity platforms, and application stores enforce accounts and access state.

Identity providers and directories are foundational. That is exactly why their job in the model has to stay clear.

A shared identity layer can improve visibility and consistency. It should support the model, not replace parts of it. A registry solves correlation.

Governance solves accountability. Implementing the operating model means keeping those jobs distinct so the whole system works together.

Start by getting clear on

• Authoritative sources for each identity type

• Whether registries already exist

• What layer makes governance decisions

• Which platforms enforce identity state

• Where ownership becomes unclear

Measure

• source to registry alignment
• registry coverage across identity types
• authoritative attribute coverage
• governed attributes enforced downstream
• local overrides to governed state

Architectures can vary. The operating model still has to define how identity truth is sourced, tracked, governed, and enforced.

Once the four jobs are clear, the next challenge is helping people understand, adopt, and sustain them across the organization.

❓Which of the four jobs is least defined in your environment today?

hashtag#IdentityManagement hashtag#IAM hashtag#IdentityGovernance hashtag#IdentityOperatingModel hashtag#IGA...show more

Read on LinkedIn

When we rolled out a new access request flow a few years ago, the technology worked exactly as designed. The forms were clean, the logic was solid, and the approvals routed perfectly. On paper, it was everything we wanted.

But the first week told a different story.

Managers were still forwarding emails instead of using the new form. App owners weren't sure what information they were expected to review. A few people didn't even know the change had gone live. Nothing was broken, people just didn't have what they needed to do the new work.

That's when it clicked. OCM isn't about communication. It's how the operating model becomes real.

We sat down with a handful of approvers for fifteen minutes each and asked what slowed them down. We simplified the request form so the decision data was right in front of them. We wrote a one-page "what to approve" guide and recorded a short walkthrough. By the next wave, adoption jumped because the change finally made sense in their day.

This is the part of the operating model most teams underestimate, the part where people actually do the new work the model requires.

Small, human-centered adjustments, not big campaigns, are what make the Modern Identity Operating Model stick.

❓Where have you seen small changes make the biggest difference in adoption?

hashtag#IdentityManagement hashtag#IAM hashtag#ChangeManagement hashtag#OCM hashtag#IdentityOperatingModel hashtag#UX hashtag#KnowledgeManagement

...more

Read on LinkedIn

A line from a conversation last week has stayed with me:

"Humans start attacks. Machines sustain them. Agents accelerate them."

That one sentence captures the shift happening across identity today.

Most organizations still treat compromise as a human problem. Phishing, MFA fatigue, and social engineering remain the entry points. But once inside, attackers look for identities the environment treats as always on, long-lived service accounts, automation identities, integrations, and machine-to-machine connections that rarely get reviewed.

Series 1 introduced the capabilities of modern identity. Series 2 moves into the operating model, how those capabilities are implemented and sustained so every identity type moves through the environment with the same discipline.

Lifecycle is where that structure becomes real.

We are now seeing identities that can create, modify, or delegate other identities on their own. LLMs and orchestration frameworks can generate identities faster than any manual control can respond. For the first time, an identity can create another identity without a human in the loop. That changes the operating landscape in a meaningful way.

Yet the industry still tries to solve these challenges in silos. PAM in one place. IGA in another. CIAM somewhere else. Modern risks don't respect those boundaries. The operating model has to unify the signals across all identity types so the environment stays predictable and healthy.

Clear ownership

Defined purpose

Preapproved access with SoD built in

Continuous authorization

Disciplined decommissioning

Lifecycle is not a workflow. It is the structure that keeps these signals aligned across humans, machines, B2B connections, and customers, the backbone of a modern identity environment.

Over the next few posts, we'll explore how lifecycle governance works across the domains that matter most: workforce identity, nonhuman and machine identity, external and third-party identity, and customer identity as its own domain.

The attack surface is changing. Our operating model can change with it.

❓Are you seeing attackers shift from human accounts to machine persistence in your environment?

hashtag#IdentityManagement hashtag#IAM hashtag#IdentityGovernance hashtag#IdentityOperatingModel hashtag#LifecycleManagement hashtag#CyberSecurity

For more than two decades, I have led identity programs through reorganizations, mergers, audits, cloud migrations, authentication modernization, and the quiet work of cleaning up what no one else wanted to touch. Across every one of those environments, the same patterns kept showing up. Unclear ownership. Broken lifecycle. Tools chosen before the problem was understood. Teams carrying responsibility they were never given the structure to hold.

I know what it is to build the plane while flying it. To fix foundations, stand up governance, and keep operations running at the same time, often with no budget to do any of it. To be told identity is critical and then handed a queue, a backlog, and an audit finding instead of a strategy.

This book is for the leaders living inside that reality.

It is not a tool guide. It is an operating model. A way to make identity predictable, trustworthy, and sustainable across governance, lifecycle, access, technology, and people. It is the framework I wish I had been handed early in my career.

If you have been reading the series here on LinkedIn, that is where the thinking lives while the book takes shape. More to share as it gets closer.

hashtag#IdentityManagement hashtag#IAM hashtag#IdentityOperatingModel hashtag#CybersecurityLeadership

Read on LinkedIn

Lifecycle is often the first place the operating model shows whether it is working.

If lifecycle signals are incomplete or inconsistent, the rest of the model cannot function.

Most organizations have gaps. Some applications sit outside IGA and rely on tickets or email. Some identity types, contractors, service accounts, external users, fall outside governed lifecycle entirely. Some lifecycle events, like transfers or leaves, never trigger access changes because HR and IAM systems don't produce reliable signals. In some environments, provisioning has been automated into applications never connected to deprovisioning. Access goes in. It does not come out.

Lifecycle can look governed from the center while the edges operate independently.

Risk accumulates at the edges.

This is where risk and change appetite from Post 7 become practical. The gaps will not all close at once. Which gaps close first, and how aggressively, depends on actual appetite. Starting with a limited set of functions and applications may be the right approach while the gap picture is being worked.

The current state inventory makes this analysis possible. Without it, gaps remain invisible.

Start by getting clear on:

• Which applications are outside IGA coverage

• Which identity types have no governed lifecycle

• Where provisioning or deprovisioning is still manual

• Which lifecycle events trigger access changes and which do not

Measure:

• IGA application coverage rate
• Identity type lifecycle coverage
• Manual provisioning and deprovisioning volume
• Orphaned account rate
• Time to deprovision on offboarding

The goal is not to close every gap at once. The goal is to know where they are and close them deliberately.

❓Where is lifecycle governance working in your environment, and where is it only assumed?

hashtag#IdentityManagement hashtag#IAM hashtag#IdentityGovernance hashtag#IdentityOperatingModel hashtag#IGA

Read on LinkedIn

Nonhuman identities now outnumber human ones in many environments. Service accounts, workload identities, API clients, automation identities, and

AI agents authenticate and act across systems every day.

The operating model still applies. The principles do not change. The patterns inside them do.

Most nonhuman identity gaps come from assuming employee patterns work here. They do not. Some nonhuman identities were created years ago with no owner. Others are created automatically by pipelines, platforms, and integrations. The model has to account for both.

Every nonhuman identity needs a named owner and a defined purpose.

Lifecycle signals come from the systems that generate them, not from tickets or tribal knowledge. Access is preapproved, scoped, and aligned to declared purpose. Cloud platforms, secret stores, and orchestration tools provide authoritative signals. Engineering, platform, security, operations, and IAM teams share accountability for what they create.

AI agents follow the same authentication and authorization patterns. They just move faster, which means the model has to be clearer.

Start by getting clear on:

Who owns each nonhuman identity and why it exists

How creation, rotation, and decommissioning signals flow

Where access is broader than the declared purpose

Which platforms and pipelines create identities outside governance

How engineering and identity teams share accountability

Measure:

• Nonhuman identities with named owners and defined purpose
• Automated rotation and decommissioning coverage
• Access alignment to declared purpose
• Time to detect and remove unowned or stale identities
• Cross-team accountability for identity creation

Nonhuman identities need the same clarity, accountability, and discipline as every other identity type.

The pace is different. The principles are not.

❓ What part of nonhuman identity governance is hardest to make real in your environment today?

Read on LinkedIn

AI agents sit inside the nonhuman identity category. The implementation patterns do not.

I have watched identity programs try to absorb agents the way they absorbed service accounts. It does not work. Service accounts are static. Agents reason about how to accomplish goals, acquire permissions at runtime, chain tools across systems, and produce action sequences their creators did not anticipate.

The implementation direction is becoming clearer. In its February 2026 concept paper on software and AI agent identity and authorization, NIST and NCCoE take a clear position: adaptation, not invention. Extend existing standards thoughtfully.

That aligns with how the operating model treats every identity type. Agents need the same things the model already names. A named owner. A declared purpose. A scope of allowed actions. A lifecycle including creation, modification, and decommissioning. Review and accountability inside the same governance structure.

Some of this can be extended from what identity teams already do.

Some cannot. Access delegation across multi-hop agent chains remains an open problem.

Runtime enforcement is still maturing. Prompt-injection resistance and tool-use boundaries are still being built. Be honest about what is solved and what is not.

The work is extending what the operating model already does to a new identity type. Same governance. Same lifecycle. Same review. Applied at a pace the model was not designed for.

Start by getting clear on:

• Which agents exist and who owns them

• Whether each agent has a declared purpose

• Whether agents are governed in lifecycle and review

• Where agents run under shared or human credentials

• Which agent capabilities exceed declared purpose

Measure:

• Agents with named owners and declared purpose
• Agents governed in lifecycle and review
• Agents under shared or human credentials
• Privileged agents without owners or expiration
• Agent activity outside declared purpose

Agent governance is not a separate operating model. It is the same model applied to a faster, less predictable pattern.

The pace is different. The principles are not.

❓ Is AI agent governance in your environment mainly an adoption gap, a capability gap, or a governance gap?

External identity governance starts where the source of truth lives. And the source of truth is rarely in one place.

In most enterprises, external identities outnumber employees, touch the same data, and have less governance behind them. More than one third of breaches now start outside the organization. External identity is where the operating model goes quiet, and where most identity programs lose.

Some of the most infamous breaches in the last decade started with an external identity. A vendor with too much access. A contractor account that lingered after the contract ended. The pattern is consistent enough that it is not a coincidence. External identity is the soft edge of most identity programs, and attackers find it.

Contractors are sponsored by managers and tracked by HR or procurement depending on the organization, and the teams given that responsibility often feel stuck. Vendors are procured by sponsors and app owners but land in IAM later, often without context. Partners are agreed at the leadership level but federated by security. Managed service providers often have privileged access with little visibility into what they are doing day to day.

And some external identities never enter through any formal path. They are created the moment someone shares a file or invites a guest to a channel. IAM may not know they exist.

The identity is created. Someone walks away from the lifecycle. The owner is unclear. The end date is informal. The access is overbroad. Six months later, it is a permanent exception.

External identities follow the same operating model as every other identity type. The principles do not change. The patterns inside them do.

Sponsor accountability is the foundation. Lifecycle is sponsor-driven, with defined end dates and renewal cycles. Access is right-sized and time-bound. The authoritative source is defined and trusted, whether that lives in HR, a vendor system, or somewhere else. Sponsors, procurement, and IAM teams stay aligned on what differs from employees, or the model breaks down at the seams.

Start by getting clear on:

Who sponsors each external identity and what decisions they own

How each external type enters and exits the environment

Where access is broader than the sponsor's stated purpose

Measure:

• External identities with defined sponsors
• Accounts with end dates or renewal cycles
• Time to remove access when external work ends

The system is not the problem. The missing operating model usually is.

❓ Which external identity type is hardest to govern in your environment today?

In every other identity domain, the organization owns the identity. With customer identity, the customer does.

That changes how the operating model applies. The source of truth lives with the customer. Consent is the ownership signal. Lifecycle follows product usage, not employment events. The organization holds the identity under obligation, not under default control.

Privacy and consent regulations have been multiplying for years. The bar keeps rising. A CIAM platform that cannot demonstrate auditable consent for every data processing purpose is no longer a gap. It is a compliance liability.

Customer identity follows the same operating model as every other identity type. The principles do not change. The patterns inside them do.

Product or business service owns customer identity, with privacy, security, and engineering supporting. Lifecycle is shaped by registration, consent, product usage, account recovery, suspension, and deletion. Access is what the customer is willing to share, governed by consent state. The authoritative source is the customer's own data and self-asserted attributes, enforced through CIAM and consent platforms. All of these owners stay aligned on what differs from employees, or the model breaks down at the customer's first bad experience.

Most product and business teams do not realize they are inside the identity operating model. They think of themselves as building customer experiences. The first implementation move is bringing them into the conversation. Get product, privacy, security, legal, and IAM together and build a shared understanding of who decides what. Call it a decision matrix, a RACI, or whatever artifact your organization uses. Consent design. Account recovery boundaries. Deletion SLAs. Cross-brand data flow. Once those decisions have owners, the rest of the model has something to encode.

Start by getting clear on:

Who owns customer identity decisions across product, privacy, security, and legal

How consent is captured, stored, honored, and synced across brands

How account recovery and deletion meet regulatory expectations

Measure:

• Whether ownership for customer identity is defined and adopted
• Whether consent state is enforced consistently downstream
• Whether account recovery and deletion meet regulatory SLAs

When customer identity is predictable, customers feel trust. When it is inconsistent, regulators notice.

The customer owns the identity. The operating model has to be built around that fact.

❓ What is the hardest part of customer identity governance to define in your organization today?

Cloud IAM is not a separate operating model. It is the same model running at machine speed, across platforms, with credentials that should expire before anyone remembers to rotate them.

When I partnered with cloud security teams in past environments, the pattern was familiar. Machine identities outnumbered human ones by significant ratios. Long-lived keys sat in code, vaults, and config files. Service principals created years ago still held privilege no one could explain. AI agents now add another order of magnitude to that surface.

The principles are not new. The cadence is.

Implementing cloud IAM as a function of the operating model means treating every cloud identity, human or not, as a governed object with an owner and a purpose. It means lifecycle discipline tied to the pipelines and platforms producing the identities. It means AI agent identity is named and governed before agents deploy, with owner, purpose, and expiration captured at creation. It means workload identity federation, where the platform issues short-lived credentials at runtime instead of stored keys, replaces long-lived secrets wherever it can. It means cloud roles reflect purpose, not convenience, and privilege expires unless renewed with intent.

Cloud discovery is continuous. Platforms generate identities faster than people can document them, and every one needs a human owner. Where the platform supports it, ownership is captured at creation. Where it does not, ownership has to follow quickly, before the identity becomes another orphan.

Sequence matters. Existing long-lived credentials need a retirement plan, not just a rotation calendar. New workloads need workload identity federation from day one. AI agents need governed identity before deployment, so they do not end up acting under shared human credentials.

Start by getting clear on:

Which cloud identities have no defined owner

Where long-lived keys and secrets still exist

Which workload and AI agent identities are overprivileged

Where role design favors convenience over purpose

Which platforms generate identities faster than governance can absorb

Measure:

• Cloud identities with defined owners, by identity type
• Long-lived keys or secrets still in use
• Workload identity federation coverage
• Privileged cloud roles without clear business purpose
• Unused or dormant workload and agent identities

Cloud IAM does not replace the Modern Identity Operating Model. It tests whether it can scale.

❓ Where is your biggest cloud identity gap: ownership, privilege design, or credential discipline?

Entitlement implementation is design, ownership, and ongoing review. Without all three, what you have is not an operating model. It is a backlog.

Most entitlements were never designed. They accumulated. A role got added during a project. A group got created for one person and outlived the reason. A permission got granted because nobody had time to figure out the right one. None of this is unusual. It is how entitlements grow when no one is implementing structure.

The discipline applies across identity types. Entitlements for employees, contractors, service accounts, and AI agents all need the same thing.

Design means entitlements that are clear, concise, scoped to least privilege, and aware of segregation of duties. Definition is how that design gets captured: a name people understand, a defined business purpose, a documented risk level, and visibility into combinations that create conflict of interest.

Application and system owners are central. They know what the permissions in their systems do. IAM cannot define entitlement meaning from the outside. IAM holds the model: defining what good looks like, providing the structure for ownership, and aligning access to job function or governed criteria. The meaning of the entitlement comes from the owner.

Review is not just access certification. Entitlements themselves need regular review: whether they still make sense, whether their risk has changed, whether their purpose still applies, whether they should be combined, split, or retired. Without this, the model drifts faster than any certification can catch.

You cannot govern entitlements you cannot explain. Start with the systems where access cannot be explained today. Apply the model where it can hold first. Expand from there.

Start by getting clear on:

Which entitlements have names and descriptions that explain what they actually do

Which entitlements have named application or system owners

Which entitlements have documented business purpose and risk level

Where segregation of duties is being enforced and where it is not

Measure:

• Entitlements with documented purpose, owners, and risk classification
• Access assignments aligned to job function or governed criteria
• SOD conflicts identified and resolved
• Entitlements reviewed and updated within defined cycles

If it cannot explain access clearly, it cannot govern it well.

❓ What is the hardest part of implementing entitlement design, ownership, or review in your environment today?

Privileged Access Management (PAM) is a specialized discipline within IAM. The operating model has to make privilege deliberate because the blast radius requires it.

The same patterns persist: standing admin rights, shared privileged accounts, emergency access never tested, privileged service accounts no one owns. Privilege is where identity risk concentrates, and implementation extends that discipline across every identity type holding elevated rights.

Implementing privilege as a function of the operating model begins with least privilege: access only when needed, scoped, and time-bound. It means privileged access used by humans is attributable to one person, delivered through dedicated admin accounts where the platform supports separation, correlated to the human in IGA, and vaulted for the highest tiers. It means privilege is not assigned to standard accounts as a rule, with documented exceptions where applications cannot support it. It means privilege is tiered by risk: the highest tier requires dedicated admin accounts and explicit approval, while lower tiers may use role activation with strong audit. And it means PAM and IGA work together, so privileged reviews run through the same certification cycle as standard access.

For nonhuman privilege, the mechanics differ but the discipline holds. Privileged credentials live in governed vaults, not in workforce password tools, code, or config files. Privileged nonhuman, cloud, and AI agent identities are governed at creation with owner, purpose, and expiration captured.

Sequence matters. Existing standing privilege needs a retirement plan. New privileged access uses time-bound elevation from day one. Privileged nonhuman and agent identities need governed creation, not cleanup.

Start by getting clear on:

How privilege is defined and tiered by risk across systems

Which humans hold privilege on standard versus dedicated admin accounts

Which credential vaults and password managers exist, and what each holds

How break-glass access is governed, tested, and monitored

Which privileged nonhuman and agent identities have no owner

Measure:

• Identities with standing privilege, by tier
• Privilege on standard versus dedicated admin accounts
• Privileged credentials outside governed vaults
• Privileged nonhuman and agent identities without owners
• Privileged review coverage tied to risk tier

Privilege does not become safer because it is documented. It becomes safer when the operating model makes it deliberate.

❓ Where is privilege still implemented for ease of use instead of security?

Authentication is where identity proves itself, whether through a sign-in, a credential issued earlier, or a chain of trust enforced at every request. People, contractors, service accounts, workloads, agents, and customers all pass through this point, and the operating model has to govern them all.

The identity leaders I talk with describe the same reality. Passkeys are being rolled out. MFA and SSO still are not, or cannot be, fully extended to legacy systems. Authentication has to be coordinated across dozens or thousands of systems while passkeys, conditional access, and session security keep advancing. Firefighting and building strategy happen at the same time, across every system. Building the plane while flying it.

Implementing authentication as a function of the operating model means deciding how each identity type authenticates and writing those decisions down as authentication standards. It means identity proofing happens before the credential is issued and again when it is recovered, not only at sign-in. It means assigning ownership for authentication configuration, conditional access, and session governance to named people, not leaving them in a tool no one is accountable for. It means encryption protects credentials and tokens end to end, and session monitoring continues after sign-in completes. It means phishing-resistant methods become the default for employees, contractors, and privileged identities alike, with exceptions documented, time-bound, and reviewed.

Implementation is also about sequence. Legacy systems that cannot accept modern authentication need a stated plan, even if that plan is compensating controls until retirement. New applications, agents, and workloads need authentication standards and credential governance before they go live.

Start by getting clear on:

Which legacy applications still sit outside governed authentication

Whether factor requirements match each identity type in the model

Whether phishing-resistant methods are the default across identity types

Whether sessions and tokens are governed after authentication

Where exceptions have become normal

Measure:

• Application coverage behind SSO
• Identities enrolled in phishing-resistant methods (FIDO2, passkeys, certificates)
• Encryption coverage for credentials, tokens, and session data
• Authentication exceptions by type
• Token and session anomalies after authentication

Authentication proves you. Governance decides if your name is on the list.

❓ Where is your authentication strongest: at the sign-in moment, before it, or after it?

Provisioning grants a user an entitlement. Authorization decides what they can do with it at the moment of access. Most identity programs govern the grant carefully and lose sight of the moment that follows. The operating model has to govern both.

The account is created, the entitlement is approved, the provisioning workflow completes, and the work stops. Even though access decisions are still being made inside the application.

That is where application-defined roles, fine-grained permissions, the rules the application itself enforces, and code-embedded authorization logic live. Same group, same provisioning, different experience inside the application. If that layer is not governed, the operating model is incomplete.

Just-in-time access and zero standing privileges make this more true, not less. They shorten the window between assignment and authorization, sometimes to minutes.

Implementing the operating model for authorization does not require a budget cycle or an organizational change initiative. It can be built in the cracks, one system at a time, in the firefighting. Most progress comes through documentation and ownership before any tooling. Inventory where authorization decisions are being made. The system catalog is where these answers belong. Name owners. Document what each application's authorization logic actually does. Pick the highest-value systems to invest your limited cycles in, and let the others be governed through honest acknowledgment and compensating controls. Modernization toward JIT and ZSP happens opportunistically, when systems are being replaced or when an audit forces a decision. The operating model meets the portfolio where it is.

Start by getting clear on:

Which applications contain authorization logic outside central governance

Where access is decided at runtime through policy engines, JIT workflows, or code

Who owns each authorization layer from both a business and technical standpoint

Measure:

• Applications with documented authorization logic and owners
• Standing privileges that could be replaced with JIT or time-bound access
• Authorization changes with no approval trace

Identity governance does not end when provisioning completes. The access decision is moving from the approval queue to the moment of access. The operating model has to follow it there, on a schedule the organization can sustain.

❓ Where do you have cycles to govern authorization today, and where are you having to accept the gap?

A workflow can succeed technically and still fail operationally. The form works. The approvals route. The connector runs. But the outcome is still wrong.

That happens when the workflow is carrying weak assumptions about ownership, entitlement purpose, or what the request is actually supposed to achieve. The technology executes. The model underneath it does not hold.

People feel it when:

They cannot tell what to request

Approvers do not understand what they are approving

Requests route to the wrong owner

Provisioning completes but the access is wrong

Manual correction becomes part of the process

A workflow with low integrity creates rework, weak decisions, entitlement growth, and shadow processes no one meant to design.

AI is starting to reshape this layer. Intelligent request recommendations, approval recommendations based on peer behavior, workflow generation from plain language. The forward direction is real. But the integrity problem starts before AI can help. If the workflow does not know who owns what, no amount of intelligence on top of it can recover what was never there.

Implementing the operating model for workflow integrity does not require replacing your IGA platform or buying a new request portal. It can be built piece by piece. Fix the worst-routing applications first. Build approver context for the highest-volume requests. Build business roles for common access patterns. Auto-provision where eligibility criteria are clear. Route through request workflows where they are not. Workflows route to owners, present entitlements, and reflect decision rights. They depend on the system catalog, the entitlement work, and the decision rights matrix being real, not aspirational.

Start by getting clear on:

Whether request options are understandable to the people using them

Whether approvers have enough information to make a real decision

Whether workflows consistently route to the right owner

Where provisioning succeeds technically but fails operationally

Measure:

• Requests requiring manual correction
• Approvals returned or rerouted
• Provisioning failures by root cause
• Access requests completed outside standard workflow

When request workflows lose integrity, people find another path. They always do.

❓ Where do your workflows lose integrity most often: request design, approvals, provisioning, or correction after the fact?

Directories are infrastructure. They are also mirrors of organizational reality. Every gap between the governance you wrote down and the reality your organization lives shows up in them first.

Governance decides what should be true. Directories and identity stores are where those decisions become technically real or do not. Accounts, attributes, groups, downstream representations. If the enforcement layer is weak, governance never fully lands no matter how good the policy looks on paper.

Most identity teams are not architecting these environments from scratch. They are managing what they inherited. Stores added during migrations that nobody fully reconciled. Application repositories doing source-of-truth work they were never meant to do. The model has to be implemented in that reality.

Most environments now span multiple identity stores at once. The seams between them are where the operating model either holds across systems or stops at the first one. They are also where attackers move, which makes enforcement consistency a security concern as much as a governance one.

Implementing the operating model for directories and identity stores does not require a consolidation project or new technology. It can be built piece by piece. Define what each store is actually for. Establish authoritative scope for each attribute. Document the enforcement chain so governance decisions reach the systems that enforce them. Identify accidental authority and either make it intentional or move it. Govern groups deliberately with named owners and review cycles. The work here depends on the foundations earlier posts named: decision rights, the system catalog, the entitlement work. Start with the highest-risk stores and the groups carrying the most access. The rest follows.

Start by getting clear on:

Which platforms enforce account and access state

Which attributes are governed centrally and where they land downstream

Which stores have become source of truth by accident

Measure:

• Governed attributes enforced downstream
• Overrides to governed state
• Unmanaged groups or directory objects
• Enforcement failures by platform

A directory that is clean, intentional, and aligned becomes a stabilizing force. A directory that is inconsistent becomes a multiplier of drift. What you see in your directory today is what your organization actually decided yesterday.

❓ Which identity store in your environment is carrying more responsibility than it was ever meant to hold?

Access reviews are often treated like a compliance task. Launch the campaign. Get the responses. Close the control.

Certifications are more useful than that when the operating model is strong. They are one of the clearest ways to validate whether ownership is real, entitlements have purpose, lifecycle is working, and access still reflects reality.

A weak certification process usually tells the truth about the environment.

It shows up when:

Reviewers do not understand the access

Ownership is unclear

Entitlements are too broad or poorly named

Local access paths are out of scope

Completion is being measured instead of accountability

That is not a certification problem. It is an operating model problem.

Reviews should not be treated as proof that governance is working. They should be used to test whether the model underneath the review is trustworthy.

Start by getting clear on:

Whether reviewers understand what they are reviewing

Whether certification scope reflects real access paths

Which systems or access types are still excluded

Whether revocations are actually enforced

Which repeated approvals point back to weak entitlement design

Measure:

• Reviewer completion versus reviewer confidence
• Access items with unclear business purpose
• Revocation completion rate
• Repeat approvals with no change in understanding
• Certifications producing meaningful remediation

A certification is only as strong as the model it is validating.

❓ Do your access reviews validate accountability, or mostly validate that the campaign closed on time?

Exceptions are often treated as administrative tasks. In identity, they are something more useful. They are signals.

There are two kinds. Filed Exceptions are the formal artifact. They are documented, approved, time-bound, with compensating controls and a named owner. Undocumented deviations are everything else. The configuration that drifts from policy. The "I had approval" with no traceable approver. The workaround that quietly becomes how things work.

I asked an application admin once why a configuration did not match our standard. They said they had approval to do it differently. No one could name who gave it, and there was no Exception on file. Maybe an auditor accepted the explanation. Maybe the system owner did not know the official path. Either way, the deviation had quietly become the design.

Filed Exceptions are honest. They tell the truth about where the model bends. Someone reviews them, sets an end date, can revoke them. The dangerous ones are the deviations nobody filed.

Both reveal where the operating model is weak. The weakness shows up in governance, lifecycle, access design, or technology.

This is why the relationship with GRC, Compliance, or whoever owns the formal Exception process matters. IAM owns the standard, so IAM has to be at the table for review, approval, remediation planning, and closure. Not as an auditor. As the trusted advisor for application admins and owners trying to meet the standard. GRC and auditors test controls. IAM owns the standards those controls were drawn from. Without IAM at the table, the Exception process is checking control language while the standard itself continues to drift. IAM also has to surface the deviations that never made it into the process, because those are the ones drifting into design.

Start by getting clear on:

Which Exceptions are filed, aging, and repeating

Which deviations exist without an Exception on file

Which ones are tied to privileged access or lifecycle gaps

Which ones exist because the standard path is too hard to use

Which ones affect nonhuman identities or AI agents

Whether IAM is at the table as a trusted advisor

Measure:

• Filed Exception volume, age, and repeat rate
• Configurations that drift from standard without Exception
• Privileged access deviations
• Lifecycle-related deviations
• Deviations affecting nonhuman or AI identities

The goal is not to eliminate every exception. The goal is to keep them visible and stop letting them become design.

❓ Which deviation in your environment never made it into the Exception process?

A dashboard can be green while the operating model is drifting.

The metric shows what was easy to count. The system shows what is actually happening. They are not always the same story.

I have watched a dashboard turn green while every IAM person in the room knew the environment was getting worse. The provisioning numbers improved. The model was drifting under all of it.

Implementation is easy to overstate. A tool is deployed. A workflow exists. A control is documented. The dashboard turns green. None of that answers the real question.

Is the operating model actually working?

That answer does not come from project status. It comes from operational evidence. Implementation is complete when identity behaves predictably under change, over time.

Every post in this series ended with a Measure section. The list is long. The harder question is whether it tells the truth.

A measurement model that holds surfaces drift before incident, distinguishes activity from health, and changes decisions. It also has to speak to three audiences.

Executives need trend direction and risk reduction. Top metrics: phishing-resistant authentication coverage, privileged access trend, AI agent governance posture.

Operational teams need action-ready signal. Top metrics: mean time to deprovision, orphaned account rate, provisioning latency.

Governance bodies need standards integrity. Top metrics: access review completion with meaningful remediation, exception trend, standards adherence.

The same data does not need to be presented the same way to everyone. Reporting becomes useful when it is role-aware.

Standardizing how these metrics are collected and rolled up across hundreds of apps is its own discipline. Without it, audience views report different versions of the truth.

Start by getting clear on:

Which metrics tell you the model is holding, not just moving

Where activity is being mistaken for health

Whether the same data tells the right story to each audience

Which metrics actually changed behavior in six months

Measure the measurement model:

• Predictability over time, not snapshot status
• Drift surfaced before incident, not after
• Activity counts separated from health signals
• Decisions changing because of what the metrics show

A measurement model that produces only dashboards is reporting. One that changes behavior is operating. The model is real when measurement shows it holding, not just moving.

❓ Where does your dashboard look green while you know something is drifting?

This series describes how the operating model should work. The honest gap is what to do when the organization will not let it.

I once watched an operating model stall for two years. The system catalog had no clear home. Data quality was in someone else's backlog. Funding for shared tooling was waiting on a cycle. None of it was wrong. All of it was reality. The story going up was still "progress."

For the operating model to work, three things have to be true. IAM has to design it. The organization has to invest in it. Collaborating teams have to deliver against it. When any of the three is missing, the model becomes theater. Visible enough to report. Not real enough to hold.

Sometimes the gap sits above IAM, where leadership has a broader lens. The work is not to argue with that view but to make sure both roadmaps are visible and navigated together.

This is not a leadership failure on IAM. It is a structural condition the operating model must be honest about. The work is to make progress anyway.

Make progress with these moves:

Quantify what the blocked dependency costs. Audit risk, manual labor, exceptions, incidents tied to the gap. Numbers move conversations frustration cannot.

Start small. A spreadsheet or SharePoint capture is not a 2026 solution, but AI can use the data to see and prioritize risk. The interim proves the value of better tooling that serves multiple teams and governance bodies. Partner with IT for the larger version.

Use AI to compress what humans cannot deliver. Generate documentation and inventories. Check standards against the model and external requirements. Surface patterns. AI shortens the runway when resources cannot.

Document the gap honestly. Make it a governance artifact, not a private burden. The risk register makes unfunded decisions visible.

Frame the gap as a decision the organization has to make. Not "the team is blocking me." Instead: "The organization has not decided to fund this. Here is what we are carrying."

Find leverage outside IAM. Audit findings and regulatory pressure create urgency IAM cannot manifest.

The operating model is a shared vision. Not built by one team. It does not hold without commitment across every dependency. IAM's job is to keep the foundation visible. To keep teaching what is being built, so the vision is shared and funded.

❓ What is one piece of your operating model's foundation that you need the organization to commit to before the rest can hold?

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #IdentityLeadership #ChangeManagement

Conclusion: The Foundation You Build Together

Series 1 was the model. Series 2 was implementation. This is the close.

I once watched an identity director explain the operating model to a room of leaders who had only seen identity through capability lists and tool inventories. Within an hour the conversation changed. Not because the framework was novel, but because it gave language to what they had been wrestling with for years. They could see the whole. They could name what was missing. They could decide what to build.

That is what the operating model does when understood as a foundation, not a framework. It gives a leader something to teach. A team something to build. An organization something to commit to.

Across this series, the same pattern kept showing up.

Identity weakens where:

• Ownership is unclear
• Source of truth is weak
• Lifecycle is incomplete
• Authorization is governed in the wrong place
• Privilege is convenient, not intentional
• Exceptions become design
• Drift becomes normal
• Operations are unowned

None of these are isolated failures. They are operating-model conditions. They show up across workforce, nonhuman, machine, customer, external, cloud, and AI-mediated identities. The model lets you see them as one system instead of nine.

That is the foundation.

Knowing the whole helps you build the parts. Teaching the whole helps the organization decide what to build next. Shared vision becomes possible because there is something to share.

The work is not finished when the implementation is.

The model has to keep holding as identity expands into territory still taking shape. AI agents outnumbering humans. Conversational interfaces. Identities that act in milliseconds. Arriving while the foundation is still being built. Series 3 will look ahead to what identity must become.

That is why the model matters. A foundation that holds only in stable conditions is not a foundation. It is a diagram.

There is no shortage of identity content in 2026. Capabilities lists. Control planes. Trust diagrams. All real. All matter. But capabilities only hold when there is something underneath. The work that endures is the foundation the organization can rely on, across leaders, teams, and tools.

This series is the structural framing. The book taking shape alongside it is the deeper work.

The operating model is not a destination. It is the foundation you build together, then keep teaching as the ground shifts.

❓ What part of your operating model are you still helping your organization understand?

#IdentityManagement #IAM #IdentityGovernance #IdentityOperatingModel #ModernIdentity #IdentityLeadership

Identity accountability is often framed as a people problem. Human error. Carelessness. Shortcuts. But most failures do not start with people. They start with the systems we expect people to operate in. Identity is not a set of controls. Identity is a system. When the system is misaligned, accountability breaks long before a breach ever does.

The Issue

Accountability breaks when identity data is incomplete or outdated. Accountability breaks when ownership is unclear. Accountability breaks when provisioning is slow or approvals are confusing. Accountability breaks when entitlements are not defined or maintained. Accountability breaks when nonhuman identities lack lifecycle controls. Accountability breaks when technical debt piles up and tools overlap or sit unused. Accountability breaks when the secure path is harder than the workaround. These gaps increase risk long before anyone notices.

How to Fix It

Begin with clean, complete identity data across all identity types. Workforce identity starts with HR, but customers, guests, service accounts, bots, integrations, and automations require the same level of discipline. Some of the highest risk identities are the ones no one sees.

Rationalize tooling and remove overlap. Fragmented environments create blind spots and inconsistent controls. Tools express the operating model. They do not replace it.

Invest in the people who run identity. Modern IAM requires current knowledge, ongoing development, and the capacity to manage complexity. Accountability is not possible when teams are under resourced or unsupported.

How to Measure It

Measure the completeness and accuracy of identity data. Measure ownership clarity for each identity and entitlement. Measure provisioning and deprovisioning cycle times. Measure the number of unmanaged or orphaned identities. Measure the volume of technical debt tied to identity behavior. Measure the number of audit findings related to identity accountability.

How to Audit It

Validate that identity data matches the truth of the organization. Validate that ownership is documented, current, and understood. Validate that lifecycle processes are followed consistently. Validate that entitlements are defined, reviewed, and maintained. Validate that nonhuman identities have full lifecycle controls. Validate that tooling is implemented as designed and not bypassed. Validate that training, development, and staffing levels support the operating model.

Strong identity programs are not built on perfect tools. They are built on people, processes, and identity data that make doing the right thing the easiest thing.

Where do you see accountability breaking down most often: identity data, lifecycle, ownership, entitlements, or technical debt?

Post ? February 2026

A LinkedIn Series by Becky Sandberg

Identity is often described in terms of tools, processes, and controls. Authentication. Entitlements. Lifecycle. Privileged access. But identity does not fail at the control level. Identity fails at the system level. When the operating model is unclear, identity becomes unpredictable. When the operating model is aligned, identity becomes a strategic capability.

Accountability in Identity and Access Management is not a people problem. It is a system problem. Most failures begin long before a breach ever does. They begin when identity data is incomplete, when ownership is unclear, when lifecycle does not reflect the truth of the organization, when entitlements drift, when technical debt shapes behavior, and when the secure path is harder than the workaround.

Identity behaves the same way regardless of who or what the identity represents. Workforce. Nonhuman. Customer. Cloud entitlements. The operating model determines how all of them behave.

Over the next several weeks, I will break down the components of the modern identity operating model and show how each one influences accountability, risk, and system behavior. Each post will explore one part of the system and how it shapes identity outcomes in practice.

Strong identity programs are not built on perfect tools. They are built on clear ownership, aligned processes, intentional governance, and identity data that makes doing the right thing the easiest thing. That is the foundation of real accountability.

I look forward to sharing this series with you.

hashtag#IdentityManagement hashtag#IAM hashtag#IdentityGovernance hashtag#CybersecurityLeadership hashtag#RiskManagement hashtag#IdentityOperatingModel hashtag#CIAM hashtag#CIEM

Read on LinkedIn

Last week's post sparked an important conversation. Many of the comments reinforced something I see across every organization I work with. Identity programs do not struggle because people are careless or because tools fall short. They struggle because identity is treated as a set of pillars instead of a system.

Most people think of an IAM program as covering everything related to identity. Authentication. Authorization. Lifecycle. Entitlements. Privileged access. And in theory, it should. But in practice, IAM, IGA, and PAM each cover only part of the work. IAM focuses on authentication and access. IGA focuses on lifecycle, entitlements, and governance. PAM focuses on elevated privilege. They are important pillars, but they are not the whole operating model.

They do not cover nonhuman identities.

They do not cover authorization logic inside applications.

They do not cover identity data quality.

They do not cover behavioral analytics or forensics.

They do not cover cross-functional decision flow.

They do not cover the policy and standards foundation that holds everything together.

When we assume IAM covers everything, we miss the system that actually determines risk. And in the spaces between those teams and tools, risk grows quietly.

Identity is not a technology stack.

Identity is an operating model.

It is people, processes, data, decisions, and governance working together or not.

Over the next several weeks, I will walk through the ten components of a modern identity operating model. Each post will focus on one component using the same structure introduced last week.

We will look at the gaps between systems. The gaps between teams. The gaps between policy and reality. The gaps where ownership disappears. The gaps where nonhuman identities grow unchecked. The gaps where entitlement creep becomes culture. The gaps where provisioning friction creates workarounds. The gaps where technical debt becomes the identity tax. The gaps where skills and support fall behind. And the gaps where AI, behavioral analytics, and forensics finally give us the truth.

Identity becomes resilient when the system is visible, the rules are clear, and the work is shared.

Next week I will start with the foundation that makes accountability possible. An honest inventory.

I would love to hear how others see these gaps show up in their own environments.

Read on LinkedIn

Every identity program depends on the quality of its data. When the information that defines a person or a nonhuman identity is inconsistent or unclear, every downstream control inherits the risk. Before lifecycle, access, or governance can work, organizations need clarity about which systems are authoritative for which attributes and strong relationships with the teams who own them. This is why identity data and source of truth integrity is the first component of the operating model.

The Issue

Most organizations do not have clear ownership for the attributes that drive identity decisions. HR systems, contractor systems, vendor feeds, and application directories all maintain their own versions of the truth. Different identity types follow different processes, and the data that describes them often lives in separate systems. When attributes conflict or change unpredictably, provisioning breaks, access reviews lose meaning, and entitlement creep accelerates. Leaders often think they have a lifecycle problem when they actually have a data problem.

How to Fix It

Define authoritative sources by attribute and by identity type. Clarify which system owns name, manager, department, employment type, and status for employees, contractors, vendors, and service accounts. Establish rules for how data flows from source systems into identity platforms. Build strong relationships with the teams who own those systems so that when business processes change, identity stays in sync. Treat identity data as a governed asset with shared accountability across the organization.

How to Measure It

Track the percentage of identities with complete and accurate core attributes. Measure the number of conflicting records across systems. Monitor how long it takes for changes in source systems to appear in downstream platforms. Look at the volume of manual corrections required each month. These metrics reveal whether the data foundation is strengthening or eroding.

How to Audit It

Validate that each attribute has a documented authoritative source. Confirm that data flows match the design. Review logs to ensure updates are processed consistently. Check for orphaned or stale records that no longer match HR or vendor systems. Interview data owners to confirm they understand their responsibilities and that communication channels are active.

A strong audit exposes misalignment early, before it becomes a security incident.

Identity data is the first component of the operating model for a reason. When authoritative sources are clear, governed, and supported by strong relationships, every downstream control becomes more reliable. When they are not, every control inherits the risk. A resilient identity program begins with a foundation leaders can trust.

Read on LinkedIn

Inventory gives you visibility. Ownership gives you accountability. Identity breaks when no one owns the data, the process, the decisions, or the outcomes. It also breaks when ownership is assumed instead of assigned.

The Issue

Ownership is fragmented across HR, IT, Security, application teams, and external partners. Each group owns a piece of the lifecycle, but no one owns the whole thing.

Identity types add complexity. Workforce, contractors, vendors, service accounts, cloud principals, workload identities, bots, and privileged identities all require clear owners. When any identity exists without an owner, it becomes a permanent exception.

How to Fix It

Treat ownership as a formal operating-model function.

Define owners for every identity type. If it can authenticate or authorize, it must have an owner.

Define owners for lifecycle actions. Creation, updates, transfers, terminations, exceptions, and emergency access all require explicit accountability.

Define owners for systems and the authorization logic inside them.

Define owners for decisions. Access approvals, exception handling, role design, and entitlement definitions must align with risk.

Define owners for governance. Policies, standards, and procedures require accountable stewards.

Validate ownership through behavioral analytics. Ownership is real only when reflected in behavior.

Modern identity visibility platforms can also help surface where ownership is drifting or unclear, giving teams a clearer picture before issues become systemic.

How to Measure It

• Percentage of identity types with defined owners
• Percentage of systems with defined owners
• Percentage of lifecycle actions with defined owners
• Percentage of entitlements with business owners
• Number of identities without validated owners
• Number of exceptions caused by unclear ownership
• Alignment between documented ownership and observed behavior

How to Audit It

Ask for the list of identity types, systems, lifecycle actions, and entitlements with their owners.

Confirm how ownership is maintained when teams reorganize.

Review how exceptions are approved.

Compare documented ownership to observed behavior in logs and analytics.

If ownership is unclear or inconsistent, accountability is not possible. Ownership is not optional. It is the structure that makes identity work.

Read on LinkedIn

Last week we talked about ownership and why accountability is impossible without it. Even with clear ownership, most organizations still have a blind spot that grows every year. That blind spot is nonhuman identities.

Nonhuman identities already outnumber workforce identities by orders of magnitude. They authenticate, authorize, move data, run automation, and connect systems. Many do all of this without lifecycle controls, without owners, and without visibility.

The Issue

Most organizations do not treat nonhuman identities with the same discipline as workforce identities. They are created quickly during automation or deployment, rarely documented, rarely reviewed, and rarely removed. Over time they accumulate privileges and become permanent exceptions.

Service accounts, application identities, cloud service principals, workload identities, bots, machine-to-machine identities, API keys, tokens, and privileged nonhuman identities all carry risk. The problem is not that they exist. The problem is that they exist without rules, owners, or governance.

How to Fix It

Treat nonhuman identities as a first-class identity population.

Define nonhuman identity types so they can be governed.

Assign owners. Every nonhuman identity needs a technical and business owner.

Define lifecycle rules for creation, updates, rotation, privilege changes, and removal.

Define access rules. They must have least privilege and documented entitlements.

Validate behavior through analytics to identify active, dormant, or overprivileged identities.

Identity visibility and intelligence platforms can surface unmanaged, orphaned, or drifting nonhuman identities before they become systemic risk.

Remove unused identities. Dormant identities are high-risk identities.

How to Measure It

• Percentage of nonhuman identities with defined owners
• Percentage with lifecycle rules
• Percentage with least-privilege access
• Number without validated owners
• Number of dormant or unused identities
• Number of privileged nonhuman identities without justification
• Alignment between documented and observed behavior

How to Audit It

Ask for the list of nonhuman identity types and their owners.

Ask how they are created, updated, rotated, and removed.

Ask how privileges are assigned and validated.

Ask how dormant identities are identified and removed.

Compare documented behavior to observed behavior in logs and analytics.

If nonhuman identities are unmanaged or unowned, the organization is carrying silent risk.

Nonhuman identities are not edge cases. They are the operating system of the enterprise. Treat them with the same rigor as workforce identities.

Read on LinkedIn

Even with clear ownership and complete inventories, identity programs fail when lifecycle rigor is absent. Lifecycle is where identity stays aligned with reality or drifts quietly into risk.

Identity drift happens when identities are created incorrectly, updated inconsistently, or not removed. It shows up in transfers without access changes, contractors who stay active, nonhuman identities that accumulate privileges, and exceptions that become normal. Drift is the buildup of small inconsistencies that become risk.

The Issue

Most organizations have lifecycle processes that look clean on paper but behave differently in practice. HR data is incomplete or delayed. Managers approve access without understanding entitlements. Application teams maintain shadow processes. Contractors and vendors follow inconsistent paths. Nonhuman identities are created outside workflows. Terminations do not always result in full removal. When lifecycle rules vary across identity types, drift becomes inevitable.

How to Fix It

Treat lifecycle as a cross-functional discipline.

Define lifecycle rules for every identity type, including workforce, contractors, vendors, external users, and nonhuman identities.

Align workforce lifecycle rules with HR.

Apply the same rigor to contractors and vendors that you apply to employees.

Define creation, update, rotation, privilege change, and removal rules for nonhuman identities.

Validate lifecycle behavior through analytics to see which actions follow the expected path.

Identity visibility and intelligence platforms can surface lifecycle drift early by showing where identities are not following expected patterns.

Remove identities that are no longer needed. Dormant identities are high-risk.

How to Measure It

• Percentage of identities created through approved workflows
• Percentage of lifecycle events triggered by HR data
• Percentage of transfers that result in access changes
• Percentage of terminations that result in complete removal
• Number of identities without validated lifecycle rules
• Number of dormant or unused identities
• Alignment between documented rules and observed behavior

How to Audit It

Ask for lifecycle rules for each identity type.

Ask how HR events trigger identity events.

Ask how contractors, vendors, and nonhuman identities are created and removed.

Ask how transfers are handled and how access is updated.

Ask how exceptions are approved.

Compare documented rules to observed behavior in logs and analytics.

If lifecycle behavior does not match lifecycle rules, identity drift is already happening.

Lifecycle rigor is not optional. It is how you keep identity aligned with reality.

Feb 20?

Post ?, Accountability

Cybersecurity accountability isn't a people problem. It's a system problem.

I've been responding to a lot of posts about human error and shortcuts. But most accountability failures in cybersecurity don't start with people. They start with the systems we expect people to operate in.

Accountability breaks long before a breach ever does.

• When identity data is incomplete or outdated

• When ownership is unclear

• When provisioning is slow or approvals are confusing

• When entitlements aren't defined or maintained

• When nonhuman accounts lack lifecycle controls

• When tech debt piles up and tools overlap or sit unused

• When the secure path is harder than the workaround

And every one of these gaps increases risk long before anyone notices.

Clean identity data for the workforce begins with HR, but that's only part of the ecosystem. Customers, guests, service accounts, bots, integrations, and automations all need the same level of discipline. Some of the highest-risk identities in an organization are the ones no one sees.

Tooling adds another layer. Many organizations have multiple systems doing the same job or tools that were never fully implemented. Fragmented environments don't just frustrate people. They create blind spots, inconsistent controls, and unmanaged risk.

There's also a pattern I see far too often. Organizations want accountability and resilience, but hesitate to invest in the people who make those outcomes possible. Training budgets get cut. Conferences are treated as optional. Professional development becomes a luxury. Meanwhile, identity systems grow more complex and the threat landscape evolves daily.

We cannot expect people to run modern identity programs with outdated knowledge.

We cannot expect accountability when teams aren't supported.

We cannot claim to manage risk if we don't invest in the people who manage it.

Investing in people is not a perk. It is part of the operating model.

It is how you reduce tech debt.

It is how you prevent identity failures.

It is how you build a culture where accountability is possible.

Strong security isn't built on perfect tools.

It is built on people, processes, and identity data that make doing the right thing the easiest thing.

No unicorns required. Just experience, pattern recognition, and a clear view of how identity systems actually behave.

Where do you see accountability and risk breaking down most often: identity data, lifecycle, ownership, entitlements, or tech debt?

hashtag#IdentityManagement

hashtag#IAM

hashtag#IdentityGovernance

hashtag#CybersecurityLeadership

hashtag#RiskManagement

hashtag#NonhumanIdentities

Feb 20? 2nd post

Identity & Access Management Specialists GroupBecky Sandberg • You3mo •

Sharing a perspective I posted earlier today. Curious how others in this group are approaching accountability in their identity programs. https://lnkd.in/dHcex_qa

Cybersecurity accountability isn't a people problem. It's a system problem.

I've been responding to a lot of posts about human error and shortcuts. But most accountability failures in cybersecurity don't start with people. They start with the systems we expect people to operate in.

Accountability breaks long before a breach ever does.

• When identity data is incomplete or outdated

• When ownership is unclear

• When provisioning is slow or approvals are confusing

• When entitlements aren't defined or maintained

• When nonhuman accounts lack lifecycle controls

• When tech debt piles up and tools overlap or sit unused

• When the secure path is harder than the workaround

And every one of these gaps increases risk long before anyone notices.

Clean identity data for the workforce begins with HR, but that's only part of the ecosystem. Customers, guests, service accounts, bots, integrations, and automations all need the same level of discipline. Some of the highest-risk identities in an organization are the ones no one sees.

Tooling adds another layer. Many organizations have multiple systems doing the same job or tools that were never fully implemented. Fragmented environments don't just frustrate people. They create blind spots, inconsistent controls, and unmanaged risk.

There's also a pattern I see far too often. Organizations want accountability and resilience, but hesitate to invest in the people who make those outcomes possible. Training budgets get cut. Conferences are treated as optional. Professional development becomes a luxury. Meanwhile, identity systems grow more complex and the threat landscape evolves daily.

We cannot expect people to run modern identity programs with outdated knowledge.

We cannot expect accountability when teams aren't supported.

We cannot claim to manage risk if we don't invest in the people who manage it.

Investing in people is not a perk. It is part of the operating model.

It is how you reduce tech debt.

It is how you prevent identity failures.

It is how you build a culture where accountability is possible.

Strong security isn't built on perfect tools.

It is built on people, processes, and identity data that make doing the right thing the easiest thing.

No unicorns required. Just experience, pattern recognition, and a clear view of how identity systems actually behave.

Where do you see accountability and risk breaking down most often: identity data, lifecycle, ownership, entitlements, or tech debt?

hashtag#IdentityManagement

hashtag#IAM

hashtag#IdentityGovernance

hashtag#CybersecurityLeadership

hashtag#RiskManagement

hashtag#NonhumanIdentities

...more

1

Like

Comment

87 impressions

View analytics

Promote this post to reach people who matter to you.

Boost

Feed post number 49

Read on LinkedIn

Last week we talked about authentication and why it is the moment where identity proves itself. Once identity enters the system, entitlements determine what it can do. Entitlements are where access becomes risk, and they are often the least understood part of the operating model.

Most organizations have thousands of entitlements across hundreds of applications. Some are roles, some are groups, some are permissions, and some are custom constructs only one team understands. When entitlements are unclear or unmanaged, identity becomes unpredictable. Entitlements are not a technical detail. They are the expression of business authority.

The Issue

Most entitlement structures grow organically. Roles are created for immediate needs. Groups accumulate privileges. Permissions are added but rarely removed. Legacy applications maintain their own logic. New applications introduce new constructs. No one has a complete view of how entitlements behave. The result is entitlement creep, meaningless access reviews, hidden privileged access, shadow authorization processes, and governance tools that struggle because the structure underneath is unclear.

How to Fix It

Treat entitlements as a governance discipline.

Define entitlement structures for each application and align them with business functions.

Align entitlements with identity types so patterns reflect how each identity operates.

Define least privilege expectations so entitlements reflect what is needed, not what is convenient.

Rationalize legacy entitlements by removing unused roles, consolidating groups, and eliminating outdated permissions.

Align entitlements with lifecycle so transfers, job changes, and terminations result in entitlement changes.

Validate entitlement behavior through analytics to identify high-risk, unused, or misaligned entitlements.

How to Measure It

• Number of entitlements per application
• Percentage documented and aligned with roles or functions
• Percentage unused or dormant
• Number assigned outside approved workflows
• Alignment between entitlements and identity types
• Number of high-risk entitlements
• Alignment between documented and observed usage

How to Audit It

Ask for the entitlement structure for each application.

Ask how roles, groups, and permissions are defined and maintained.

Ask how entitlements are assigned and how exceptions are approved.

Ask how entitlement changes align with lifecycle events.

Ask how privileged entitlements are identified and governed.

Compare documented entitlements to observed behavior in logs and analytics.

Entitlements are not optional. They are the expression of business authority and the foundation of access governance.

Read on LinkedIn

Last week we talked about entitlements and why they are the expression of business authority. Privileged access is different. It is the ability to change systems, configurations, data, and controls. It is the ability to bypass safeguards and cause impact quickly. Privileged access is where identity risk concentrates.

Privileged access is not a role or a group. It is a level of authority that requires a different operating model. When it is unmanaged, the organization loses control of its most sensitive actions.

The Issue

Most organizations treat privileged access as an extension of standard access. Admin roles are assigned permanently. Exceptions are broad. Legacy groups remain untouched. Break glass accounts are never tested. Service accounts accumulate privileges without rotation. Privileged access hides inside standard roles, persists after job changes, and is often invisible to the teams responsible for governing it. Attackers focus on privileged access because it is the shortest path to impact.

How to Fix It

Treat privileged access as its own discipline.

Define privileged access for each system so elevated permissions and sensitive functions are documented and understood.

Separate privileged access from standard access. Permanent privileged access must be justified, reviewed, and monitored.

Implement time-bound elevation so privileged access is granted only when needed and for the minimum time required.

Align privileged access with lifecycle so job changes and terminations result in privileged access changes.

Govern service accounts and nonhuman privileged identities with rotation, monitoring, and clear ownership.

Validate privileged access behavior through analytics to understand how elevation occurs in practice.

How to Measure It

• Number of identities with permanent privileged access
• Percentage of privileged access that is time bound
• Number of privileged identities without justification
• Number of privileged access exceptions
• Rotation status of privileged service accounts
• Alignment between documented and observed privileged access

How to Audit It

Ask for the definition of privileged access for each system.

Ask how privileged access is assigned, elevated, and removed.

Ask how privileged access aligns with lifecycle events.

Ask how privileged service accounts are governed and rotated.

Ask how privileged access is monitored and how anomalies are escalated.

Compare documented privileged access to observed behavior in logs and analytics.

Privileged access is not optional. It is the point where identity risk concentrates and the point where governance must be strongest.

Read on LinkedIn

Last week we talked about privileged access and why it is where identity risk concentrates. Strong controls only work when people actually use them. This is where friction becomes an operating model issue. Friction is not about convenience. Friction is about behavior. When identity processes create unnecessary friction, people find ways around them, and those workarounds weaken the entire operating model.

Friction is not a user problem. It is a governance problem. When authentication, entitlements, lifecycle, and privileged access are inconsistent or confusing, users adapt in ways that create risk.

The Issue

Most organizations treat friction as a training issue. In reality, users resist security because the system behaves unpredictably. Prompts appear at the wrong time. Access requests take too long. Approvals are unclear. Privileged elevation is inconsistent. Exceptions are easier than the intended path. Application teams maintain their own processes because centralized ones feel slow or disconnected. These patterns create shadow identity processes that bypass governance and increase risk.

Friction also appears when leaders do not agree on what belongs in policy, standards, or procedures. Misalignment at the governance layer creates mixed signals, unclear ownership, and stalled decisions. Leadership friction becomes operational friction.

How to Fix It

Treat friction as a signal.

Identify where friction appears across authentication, access requests, approvals, elevation, and onboarding.

Align identity processes with how people work so identity supports workflows instead of interrupting them.

Reduce unnecessary steps by removing redundant approvals and simplifying access paths.

Improve transparency so users understand what is happening and why.

Validate user experience through analytics to see where friction leads to drift.

Align friction with risk. High-risk actions should have friction. Low-risk actions should not.

How to Measure It

• Time to complete access requests
• Time to complete privileged elevation
• Number of exceptions created to bypass friction
• Number of shadow processes identified
• Number of user complaints
• Alignment between friction and risk
• Number of abandoned workflows

How to Audit It

Ask where friction appears in workflows.

Ask how long access requests and approvals take.

Ask how privileged elevation behaves in practice.

Ask how exceptions are created and why.

Ask how users are informed about timelines.

Compare documented workflows to observed behavior in logs and analytics.

Friction is a signal that the operating model needs alignment. When friction is intentional and aligned with risk, identity becomes predictable. When friction is accidental, identity becomes unpredictable.

Read on LinkedIn

Technical debt is the accumulation of past decisions that no longer reflect how the organization works today. It shapes identity behavior, determines how controls function, and defines how much drift the organization tolerates. Technical debt is identity debt.

Technical debt is not a backlog. It is the gap between how identity should work and how it actually works. When that gap grows, the operating model becomes unstable.

The Issue

Most organizations underestimate how much technical debt influences identity. Legacy directories maintain outdated attributes. Applications rely on custom logic that bypasses controls. Entitlements accumulate privileges no one remembers assigning. Lifecycle depends on manual steps. Privileged access persists inside old roles. Identity tools reflect assumptions that no longer match the environment.

Tool sprawl is only the symptom. The real debt is the inconsistent logic, ownership, and decision making that allowed it to grow. Technical debt creates inconsistent behavior across authentication, entitlements, lifecycle, and privileged access. Identity teams spend more time compensating for technical debt than improving the operating model.

How to Fix It

Treat technical debt as a risk.

Identify where debt appears across directories, applications, workflows, entitlements, and privileged access.

Prioritize debt that affects identity behavior or weakens governance.

Align technical debt with lifecycle so drift becomes visible and manageable.

Rationalize legacy systems by removing unused attributes, retiring custom logic, replacing manual steps, and simplifying entitlements.

Improve integration patterns so identity does not rely on outdated connectors or scripts.

Validate behavior through logs and analytics to see where technical debt creates unpredictable outcomes.

How to Measure It

• Number of legacy systems with custom logic
• Number of entitlements with unclear purpose
• Number of manual lifecycle steps
• Number of outdated integrations
• Number of privileged roles embedded in standard access
• Alignment between tools and current business processes
• Number of audit findings tied to outdated configurations

How to Audit It

Ask how technical debt is identified and prioritized.

Ask how legacy systems handle authentication, entitlements, and lifecycle.

Ask how custom logic is documented and maintained.

Ask how privileged access is embedded in legacy roles.

Ask how integrations are monitored and updated.

Compare documented processes to observed behavior in logs and analytics.

Technical debt is not optional. It is the accumulation of past decisions that shape identity today. When governed intentionally, identity becomes predictable. When ignored, identity becomes unpredictable.

Read on LinkedIn

Exceptions are the moments when the operating model breaks down and people create their own path to get work done. They are not rare or harmless. Exceptions reveal how identity actually works.

Most organizations treat exceptions as administrative tasks. In reality, exceptions are signals. They show where governance is unclear, where processes do not align with work, and where controls are not functioning as intended.

The Issue

Exceptions appear when identity processes are slow, confusing, or disconnected from how people work. Users request access outside the standard path. Managers approve access without reviewing it. Application teams bypass workflows. Administrators grant permanent elevation because temporary elevation feels unreliable. Vendors rely on manual steps. Exceptions also appear when governance is unclear. Policies, standards, procedures, and system behavior do not align. Leaders disagree on requirements. Application teams interpret rules differently.

How to Fix It

Treat exceptions as data.

Identify where exceptions appear across authentication, access requests, approvals, elevation, onboarding, and vendor access.

Analyze why exceptions are needed to reveal slow, unclear, or misaligned processes.

Align exceptions with risk. High-risk exceptions require justification and monitoring. Low-risk exceptions require process improvement.

Reduce unnecessary exceptions by simplifying workflows, improving entitlement clarity, strengthening lifecycle, and modernizing integrations.

Validate behavior through logs and analytics to identify legitimate, repeated, and systemic exceptions.

How to Measure It

• Number of exceptions per month
• Percentage that bypass standard workflows
• Number of repeated exceptions
• Number related to privileged access
• Number caused by unclear entitlements or lifecycle gaps
• Alignment between exception volume and risk

How to Audit It

Ask how exceptions are defined, approved, tracked, and reviewed.

Ask how exceptions align with policy, standards, and procedures.

Ask how repeated exceptions are analyzed and addressed.

Ask how exceptions affect authentication, entitlements, lifecycle, and privileged access.

Compare documented workflows to observed behavior in logs and exception records.

Exceptions are not optional. They are the clearest signal of where the operating model needs alignment. When governed intentionally, identity becomes predictable. When ignored, identity becomes unpredictable.

Read on LinkedIn

Drift is what happens when identity moves away from the intended state over time. It is not a failure of tools or users. Drift is the natural outcome of an operating model that is not aligned. It appears slowly, accumulates quietly, and becomes normal without anyone noticing.

Drift is the widening gap between how identity is designed to work and how it actually behaves. When drift grows, identity becomes unpredictable.

The Issue

Drift appears when lifecycle is inconsistent. Transfers do not update access. Terminations do not remove access. Contractors and vendors remain active after their work ends.

Drift appears when entitlements are unclear. Roles accumulate privileges. Groups expand. Permissions are added but never removed. Reviewers approve access without understanding it.

Drift also appears when legacy logic and outdated integrations create inconsistent behavior.

Drift is the predictable result of misalignment across governance, process, technology, and behavior.

How to Fix It

Treat drift as a system signal.

Identify where drift appears across lifecycle, entitlements, and integrations.

Align lifecycle with the truth of the organization.

Strengthen entitlement clarity so drift becomes visible and correctable.

Govern privileged access intentionally with time-bound elevation and monitoring.

Reduce exceptions by making the intended path work.

Address technical debt so identity behaves consistently.

Validate behavior through logs and analytics to see where drift is growing.

How to Measure It

• Number of identities with access that does not match their role
• Number of entitlements assigned outside approved workflows
• Number of lifecycle events that do not propagate
• Alignment between documented entitlements and observed usage
• Number of audit findings related to inconsistent access

How to Audit It

Ask how drift is identified and monitored.

Ask how lifecycle changes propagate.

Ask how entitlements are documented and maintained.

Ask how privileged access is reviewed.

Ask how exceptions are analyzed.

Compare documented processes to observed behavior in logs and configurations.

Drift is not optional. It is the natural outcome of an operating model that is not aligned. When drift is governed intentionally, identity becomes predictable. When ignored, identity becomes unpredictable.

Read on LinkedIn

Authentication is the moment where identity proves itself. It is not a tool setting or a factor choice. It is the front door of the operating model, the point where identity enters the system and where risk becomes visible.

Authentication succeeds or fails based on the strength of the operating model behind it.

The Issue

Most organizations treat authentication as a technical decision instead of a governance function. MFA is deployed but exceptions are broad. SSO is implemented but key applications remain outside it. Conditional access is inconsistent. Authentication fragments across identity providers, cloud platforms, legacy systems, and application logic. Each system enforces its own rules, creating friction, blind spots, and unpredictable behavior.

Authentication breaks when identity types are not aligned, when lifecycle does not drive factor requirements, when privileged access uses weaker authentication, and when nonhuman identities bypass authentication entirely. These are not tool problems. They are operating-model problems.

How To Fix It

Treat authentication as a governed capability.

Define authentication requirements for every identity type, workforce, contractors, vendors, external users, service accounts, application identities, and privileged identities.

Define factor requirements aligned with risk and business sensitivity.

Align conditional access with lifecycle, entitlements, and identity types.

Bring applications behind SSO so authentication logic is consistent.

Eliminate unnecessary exceptions and document the ones that remain.

Validate authentication behavior through analytics and sign-in logs.

Align privileged access with phishing-resistant authentication.

Authentication must reflect identity truth, not convenience.

How To Measure It

• Percentage of identities enrolled in required factors
• Percentage of applications behind SSO
• Percentage of privileged identities using phishing-resistant authentication
• Number of authentication exceptions
• Alignment between conditional access and identity types
• Number of sign-in events that bypass controls

How To Audit It

Ask for authentication requirements for each identity type.

Ask how factor enrollment is enforced.

Ask how conditional access is defined and maintained.

Ask how applications are onboarded to SSO.

Ask how privileged identities authenticate.

Compare documented rules to observed behavior in logs and analytics.

Authentication is not optional. It is the moment where identity proves itself and the moment where risk becomes visible.

Read on LinkedIn

Over the past several weeks we have looked at identity from many angles. Authentication. Entitlements. Lifecycle. Privileged access. Friction. Technical debt. Exceptions. Drift. Each topic stands on its own, but none of them operate on their own. Identity is not a collection of controls. Identity is a system. The operating model is what makes that system work.

Identity Is Not a Tool Problem

Tools express the operating model. They do not replace it. When the operating model is unclear, tools behave inconsistently. When ownership is fragmented, tools overlap. When governance is weak, tools drift.

Identity Is Not a Human Problem

Users do not create friction because they dislike security. They create friction because the system behaves unpredictably. Managers approve access blindly because entitlements are unclear. Application teams bypass workflows because the intended path does not work.

Identity Is Not a Workforce-Only Problem

The same operating-model principles apply to customer identity, cloud entitlements, and nonhuman identities. When ownership, lifecycle, and entitlements are unclear, all identities behave the same way.

The Operating Model Is the Foundation

The operating model defines who owns identity, entitlements, lifecycle, privileged access, decisions, exceptions, and governance alignment. It defines how identity aligns with business processes, how controls are implemented, how risk is managed, and how behavior is monitored. It is not documentation or a diagram. It is the system that makes identity real.

The Operating Model Must Be Intentional

Strong operating models are built on clarity. Clarity of ownership, accountability, entitlements, lifecycle, privileged access, decision authority, and risk posture. When clarity is missing, identity becomes unpredictable. When clarity is present, identity becomes a strategic capability.

The Operating Model Is the Work

Identity is not a project or a deployment. Identity is the continuous alignment of people, process, technology, and behavior. Strong operating models are designed, governed, and maintained with intention. That is the real work of identity leadership.

I would love to hear how others define and strengthen their identity operating model.

Read on LinkedIn