Identity and Access Security: How the Role Actually Works

Editorial Note: This article combines established identity security practices with illustrative scenarios and emerging developments in AI agent governance. Harborline and Cedarline are fictional companies, and their scenarios do not describe real incidents. Product capabilities, licensing, and log retention vary by vendor and plan; verify current documentation before implementation.

Identity and Access: What the Role Actually Owns, and Where the Tool Stack Fits

Two Incidents, One Missing Capability

Harborline: an investigation with a missing timeline

Harborline is a 2,000-person B2B SaaS provider whose customer data lives in Microsoft 365. On a Tuesday morning, a finance analyst received an email claiming to share a quarterly report. She clicked the link, signed in on a convincing lookalike page, and completed MFA. The sign-in succeeded, and on a subsequent consent screen she approved a third-party application requesting Mail.ReadWrite and Sites.ReadWrite.All.

Three days later, the security team noticed outbound traffic that matched no known integration. The investigation uncovered two problems: the application had been granted broad access to mailbox and SharePoint data, and a service account named svc-reporting had tenant-wide read-write permissions. Created in 2019, the account had no registered owner, had not been rotated according to policy, and had never appeared in an access review. The investigation had to establish whether the compromised application, a stolen token, or another identity path had been used to reach the account and the affected data.

The post-incident review surfaced three findings. The Conditional Access policy in scope covered browser-based sign-ins but did not adequately address legacy authentication clients such as IMAP and Exchange ActiveSync. Sign-in and audit logs were retained for only 30 days under the licensing and logging configuration in place at the time, leaving investigators unable to reconstruct some earlier activity. And the service account sat outside IGA scope with no registered owner — a high-privilege asset that nobody had ever claimed.

Cedarline: a questionnaire that stopped the room

Cedarline is a 5,000-person manufacturer with dozens of customers in its supply chain. Its annual SOC 2 Type II audit arrived alongside vendor security questionnaires from three enterprise customers. The auditor skipped the architecture discussion and asked one question: please provide account deprovisioning records for the past twelve months.

The answer was not good. Internal policy promised revocation within one business day of termination. The actual median was 11 days, the 95th percentile was 47 days, and three terminated employees had authentication events recorded after their last day. A shared operations account, ops-shared, was used by 14 people, which made attribution of any single action impossible. 127 contractor accounts had no registered owner. For three consecutive quarters, the approve-all rate on access certifications ran at 96%, and the review records contained checkmarks with no stated reasoning.

No technical control had failed. MFA was on, SSO was on, and the bastion host was recording sessions. What failed was the record quality along the chain that answers a simple question: who, in what capacity, was allowed to do what, and what trace did it leave behind.

Two stories, one set of gaps

The two incidents share no characters, no systems, and no timeline. They point at the same capability gaps. One shows an attacker walking a reachable privilege path to a bad outcome. The other shows governance records that could not survive an audit. Together they define what this layer of security work actually produces: the ability to reconstruct what happened, and the ability to prove that controls were operating. The rest of this article follows those two threads.

What the Identity and Access Role Actually Owns

Strip away the product vocabulary and this layer manages three objects, three functions, and one lifecycle.

The objects are people (employees, contractors, vendors, temporary staff), machines (service accounts, API keys, certificates, workloads, AI agents), and privilege (domain admins, root, DBAs, cloud platform administrators). The functions are authentication (proving who you are), authorization (deciding what you may do), and accounting or auditing (recording what you did). The lifecycle covers onboarding, role changes, and offboarding — commonly called JML for Joiner-Mover-Leaver — plus expiry and revocation of temporary grants.

This layer rarely blocks an attack outright. It determines how far an attack travels once something gets in. The industry term is blast radius. The same initial access landing on an account with mailbox read rights produces a materially different outcome than the same access landing on an account with tenant-wide read-write and a lateral path to a domain controller. Compressing that radius is the core deliverable of the role.

Front-line engineers and executives care about different things, and that difference shapes everything downstream. Engineers care whether a change is inspectable, reversible, and observable: can a permission change be staged, rolled back, and traced when something goes wrong. Executives care whether the organization can prove and commit: can audit evidence be produced, can an SLA be honored, can risk be expressed as a trend line. A working identity program feeds both. Programs that feed only one tend to decay into compliance paperwork nobody reads, or into technical work nobody approves.

How to Layer an Identity Security Tool Stack by Timescale

Most discussions of identity tooling lay products out as a flat list. A more useful framing sorts them by the timescale on which each layer answers questions, because the layers operate at radically different speeds and answering the wrong question at the wrong speed is where programs stall.

Layer	Typical tools	Role	Timescale	Primary output
Policy decision point (PDP)	Entra ID / Okta / Ping	Per-access admission decisions: conditional access, MFA, device state, risk signals	Milliseconds	Sign-in logs, audit logs, risk signals
Identity governance (IGA)	SailPoint / Saviynt	JML automation, access requests and approvals, certifications, role mining, segregation of duties	Days to weeks	Entitlement records, certification records, approval trails
Identity threat detection and response (ITDR)	CrowdStrike Falcon Identity, Entra ID Protection	Detection and containment of credential abuse, token and ticket abuse, MFA fatigue, reconnaissance	Minutes	Alerts plus enforcement actions
Structural risk assessment	BloodHound / PingCastle	Attacker-reachable paths plus baseline and maturity scoring	Quarterly	Attack paths, tier violations, health scores

This framing explains why a single large platform rarely closes the gap. A PDP cannot answer whether an account should still hold a given entitlement in three months. IGA cannot revoke a live session in the fourth minute of an attack. ITDR has a behavioral rather than topological field of view, so structural problems stay invisible to it. BloodHound will show a three-hop path to Domain Admins and will not close it.

The seams between layers are where incidents actually live. When ITDR flags a credential as suspect, the value comes from enforcement at the authentication point — adding the account to a watchlist, forcing step-up MFA, revoking sessions, blocking specific protocols or target hosts. If that chain only produces a ticket, the detection has limited operational worth. Test the detection-to-enforcement path during selection and acceptance rather than reading it off a feature list.

Once the layers are separated, the first real disagreement appears: which system is the authoritative identity source.

Choosing an Authoritative Identity Source and Keeping Accounts Reconciled

Define an authoritative source for each identity domain and critical attribute. A second, manually maintained account list can create shadow accounts, conflicting records, and ownerless identities. A common pattern uses HR or master data as the authoritative source for workforce attributes, synchronizes identities to a directory or cloud identity provider, and provisions downstream accounts through SCIM or APIs. Other identity populations, such as contractors, vendors, service accounts, and machine identities, may require different authoritative systems. The architecture should document which source governs each population and attribute, how conflicts are resolved, and how exceptions are reconciled.

Running two IdPs can fragment risk visibility. Entra ID may govern Windows and Microsoft 365 while Okta or Ping handles access to other SaaS applications. In a federated or chained configuration, each provider evaluates the signals available to it; an anomalous sign-in detected by one provider is not automatically available to the other's access policies. The actual visibility gap depends on the federation design, available risk integrations, and policy configuration. Workable mitigations include aggregating sign-in and audit logs from both sides into a SIEM, integrating supported risk signals where available, and coordinating detection and response through an ITDR layer. The architecture documentation should state where identities originate, where group membership is computed, which system evaluates each access decision, and how a risk finding in one system triggers action in the other.

Approved access and effective access can drift apart. An IGA entitlement record captures the access represented in the governance process; directory and application configurations determine the permissions actually available to an identity. These views may differ because of direct assignments, nested group membership, inherited permissions, temporary grants, application-local roles, or accounts outside IGA scope. Without discovery and reconciliation, discrepancies can remain undetected until an audit or incident. Track the variance count as an ongoing metric, investigate material differences, and document which systems and permission types are included in the reconciliation.

With the source of truth settled, the next question is how each individual access request gets decided.

Conditional Access Policies Are Production Changes

Conditional Access is a high-impact control surface in this layer because a misconfigured policy can lock out users or administrators, interrupt business-critical workflows, or leave intended access paths insufficiently protected.

Several practices help reduce deployment risk.

Run what-if and report-only first. Evaluate policy impact against real sign-in data before enforcement. The observation period should be long enough to capture relevant usage patterns and exceptions; one to two weeks can be a starting point, but seasonal workloads and infrequent administrative tasks may require longer. Review legacy clients, mobile applications, unmanaged devices, service accounts, and emergency-access accounts explicitly.

Layer the policies. A workable structure includes an all-user baseline, stronger requirements for high-risk applications, dedicated controls for administrators, and carefully monitored emergency-access accounts. For example, the baseline may require MFA and block legacy authentication where supported and appropriate. Keep the policy set manageable, document exclusions and interactions, and verify how the policies combine before enforcement.

Use device state and risk signals where the architecture supports them. Named IP locations can be useful, but changing egress addresses or VPN routes can make location-based policies brittle. Managed-device compliance, device registration or join state, and identity risk signals can provide additional context; their reliability depends on deployment coverage, licensing, and the quality of the underlying signals.

Treat session lifetime and continuous evaluation separately. A single check at sign-in no longer holds up against token theft; long-lived sessions combined with token abuse are a mainstream technique.

Manage policies as infrastructure. Use the Microsoft Graph API, Terraform, or Bicep, with consistent naming and a documented rollback path. Treating policy as configuration rather than as console clicks makes changes reviewable and reversible.

Before designing anything, take a census of what is actually in use. This KQL query is a common starting point for measuring the impact of blocking legacy authentication (field names and values vary by tenant configuration and should be adjusted accordingly):

// Last 30 days: authentication protocol census, used to size the impact of blocking legacy auth
SigninLogs
| where TimeGenerated > ago(30d)
| where isnotempty(UserPrincipalName)
| summarize logins = count(), users = dcount(UserPrincipalName)
          by AuthenticationProtocol, AppDisplayName
| order by logins desc

Once that table exists, "can we block legacy authentication" stops being a debate and becomes a calculation.

Policy enforcement is one thing. Being able to look afterward is another.

Log Retention Windows and the Evidence Gap They Create

Harborline's investigation illustrates the risk: once relevant logs expire, investigators may be unable to reconstruct the full sequence of events.

As of October 2026, Microsoft's published retention guidance lists seven days for Microsoft Entra ID sign-in and audit logs under the Free tier, and 30 days under both P1 and P2. Risky sign-ins have a separate retention window: seven days under Free, 30 days under P1, and 90 days under P2. Microsoft 365 and Microsoft Purview licensing can introduce additional audit-retention options, so the effective window should be verified against the tenant's actual licensing and configuration. Okta documents a 90-day retention period for System Log events. Retention requirements and available options vary by log type, service, and plan; organizations that need longer investigative windows should export the relevant records to separately managed storage before the source retention period expires. A license change does not restore records that have already been deleted.

Three operational requirements follow.

Export sign-in and audit logs to long-term storage from day one. Log Analytics, Azure Storage, or a SIEM all work. The point is that the export path must be independent of the platform's internal retention window.

Monitor the health of the log pipeline as its own control. Subscription changes, an accidentally modified diagnostic setting, an exhausted quota, or an unchecked diagnostic category can all cause a silent break. Breaks are usually discovered at the moment logs are needed, which is the worst possible time.

Derive retention requirements from commitments and regulation, working backward. Contractual forensic-cooperation clauses, sector rules such as DORA in financial services or PCI DSS for payments, and the organization's own incident response policy each set a floor. That floor belongs in written policy rather than in someone's memory.

The cloud side is covered. A large share of privilege still lives in Active Directory.

BloodHound vs. PingCastle: Two Different Questions About Active Directory

These two tools are often discussed as competitors. They answer different questions.

PingCastle produces a quantified, reportable, trendable health picture. It examines stale objects, trust relationships, privileged account configuration, delegation settings, legacy protocols (unsigned NTLM and LDAP), and audit coverage, then emits a score and a prioritized list. Its value is a quarterly curve that can be shown to leadership as evidence of movement.

BloodHound produces attacker-reachable paths. It models ACLs, group membership, GPOs, delegation, certificate templates, and cross-domain trust into a graph, and answers how many hops separate an ordinary account from Domain Admins. Kerberoasting candidates, ADCS template issues in the ESC family, and short paths to Tier 0 all fall within its scope.

On remediation, chasing zero findings is rarely realistic; cutting the shortest path to Tier 0 with the smallest change set is. Prioritize by path length, multiplied by blast radius, divided by remediation cost. Common moves include reducing the number of domain admins, cleaning up legacy elevated objects (AdminCount-related), normalizing protected groups and AdminSDHolder, enforcing tier separation between management workstations and daily-use endpoints, deploying LAPS broadly, enabling LDAP signing and channel binding, limiting SPN counts per account, fixing certificate templates, and removing shared local administrators.

Collection is itself a risky operation and needs its own controls. The permissions SharpHound and azurehound require, plus the SIDs, group memberships, and ACLs in their output, are highly sensitive assets. Use a low-privilege read-only account, scope the collection, encrypt and classify the results, and purge them afterward. A risk-reduction exercise should not create a new risk source.

Beyond structural findings, the largest share of day-to-day work is access requests and reviews.

Identity Governance Lives or Dies on Approval Quality

Cedarline's 96% approve-all rate is the clearest symptom of failed IGA adoption: process present, judgment absent.

Replace annual bulk certification with risk-tiered, continuous review. Asking everyone to review everything at once produces clicking. Ordering by risk — high privilege, cross-system access, contractor and vendor accounts, long-unused permissions first and most frequently — concentrates attention where it matters.

Give approvers context. Peer-role comparison, last-use date for the permission, and the stated business justification. Without those three, approvers guess, and guessing resolves to "approve" almost every time.

Track the approve-all rate as a metric. A rising ratio usually indicates a design problem in the review, not that every permission is genuinely justified.

Use role mining to derive baselines from existing access. Hand-designed RBAC roles tend to drift from reality. Role sets modeled from actual usage data — a capability in both SailPoint and Saviynt — tend to have better coverage and maintainability.

Three numbers provide a practical starting point for demonstrating IGA value: JML automation rate, provisioning turnaround time, and deprovisioning SLA attainment. Each can be measured from operational records, and together they help demonstrate whether identity lifecycle controls are working as intended. Which measures are required for an audit or customer questionnaire depends on the applicable control framework, contractual commitments, and assessment scope.

Outside the process, there is a population of exceptions that will not be eliminated quickly.

Privileged Accounts, Break-Glass Access, and the Exception Register

Privileged accounts follow three rules: no sharing, no indefinite lifetimes, no plaintext. Converting shared accounts to individually named accounts with vault-mediated credential filling satisfies attribution without anyone needing to know a password. Just-in-time elevation with automatic expiry is far more reliable than a reminder to clean up later.

Seal break-glass accounts rather than leaving them idle. Two-person unlock, mandatory post-use review and rotation, and independent monitoring keep an emergency channel from becoming a standing backdoor.

Register exceptions explicitly. Legacy applications without MFA support, CI/CD service accounts, vendor accounts, and shared operational accounts cannot all be removed at once. Log each one with an owner, a risk statement, compensating controls (network isolation, dedicated accounts, enhanced monitoring), an end date, and a review date. Unregistered exceptions are the ones that surface badly in audits and post-incident reviews.

Give machine identities their own register. Service accounts, API keys, and certificates frequently carry the broadest privileges, rotate the least, and go unowned when people leave. svc-reporting at Harborline is the standard specimen.

Whether any of this is actually happening eventually has to be expressed in numbers.

Identity Security Metrics You Can Actually Measure

A metric is only operational if its numerator, denominator, and data source are defined; otherwise two people compute different values from the same environment. The table below specifies measurement method only. Target values should come from an organization's own policy commitments, contractual SLAs, regulatory requirements, or historical baseline trend — importing someone else's benchmark is neither rigorous nor accountable.

Metric	Definition (numerator / denominator)	Data source	Frequency	How to read it
Deprovisioning SLA attainment	Terminated accounts revoked within the policy window / all terminated accounts in period	IGA tickets + directory change timestamps	Monthly	Compare against the organization's own commitment; report median and P95, since a mean hides the long tail
Provisioning turnaround	Distribution of time from approval to usable access	IGA timestamps	Monthly	Median and P95; trend matters more than the absolute value
Entitlement variance count	Entries where directory/application actual access differs from IGA entitlements	Account discovery output	Monthly or quarterly	Track direction of travel; absolute value scales with system count
Accounts without an owner	Accounts with no registered responsible party, including service accounts and contractor accounts	Asset register + IGA	Quarterly	Target is zero; any nonzero value is an open item
Shared account count	Accounts used by two or more people	Directory + bastion session attribution	Quarterly	Each reduction improves attributability by one step
MFA coverage	Interactive accounts with enforced MFA / accounts that should have enforced MFA	IdP policy + directory	Monthly	Define the denominator explicitly (service accounts, legacy apps in or out)
Privileged account ratio	Accounts holding high privilege (domain admin, root, cloud platform admin, etc.) / total accounts	Directory + PAM	Quarterly	Watch the trend and the source of new additions
Long-unused privilege	Accounts holding high privilege with no use in N days	Logs + IGA	Quarterly	Define N in policy; the number itself is a policy choice
Certification completion and approve-all rate	Completed reviews / reviews due; approvals without stated justification / all approvals	IGA certification records	Quarterly	A rising approve-all rate points at review design
Log pipeline health	Time since last successful write per log source, against a threshold	Pipeline monitoring	Continuous	Alert on break; this is a state, not a ratio
Anomalous authentication events	Count of risky sign-ins, impossible travel, unusual location sign-ins	IdP risk signals + SIEM	Weekly	Compare to baseline; a spike requires attribution
Elevation events	PAM-initiated temporary elevations, plus elevations not revoked by expiry	PAM	Monthly	Unrevoked-by-expiry should be zero

Two additions. Trend beats snapshot: four consecutive quarters of a curve say more about program health than a single "fully compliant" screenshot. And every metric must trace back to a raw record — a number that cannot be tied to a ticket or a log line will be challenged on the spot during an audit.

A large share of the work behind these numbers is repetitive: reading tables, writing documents, querying logs, mapping controls. Generative AI absorbs a meaningful portion of it.

Generative AI in Identity and Access: Where It Helps and Where It Cannot

Platform-native AI is a practical starting point for identity-security workflows, provided that data access, permissions, and action logging are verified for the specific deployment. Keeping analysis within an organization's existing security platform can reduce data movement, but it does not by itself guarantee least-privilege access or complete auditability. Microsoft Security Copilot in Entra supports natural-language investigation of risky users, risky sign-ins, audit logs, and application risks, including granted permissions and unused applications, and can provide contextualized findings and recommendations. On the governance side, products from SailPoint, Saviynt, and Okta offer different combinations of access recommendations, governance analytics, and workflow automation. The exact capabilities, licensing requirements, and degree of automation vary by product and configuration, so verify each claimed function against current product documentation before selecting or deploying it. In ITDR and SIEM workflows, alert summarization and investigation assistance can reduce manual analysis, but response-time improvements should be measured rather than assumed.

One caution: these capabilities typically inherit the caller's permissions. Deciding who gets access to them, and at what role, is itself an authorization decision, and mishandling it amounts to privilege escalation by another route.

Scenarios that work today without any platform integration:

Report triage and remediation ranking. Feed a PingCastle report or a BloodHound export (de-identified) to a model for deduplication, grouping, and ranking by risk against remediation cost, then generate remediation tickets with acceptance criteria. This is pure mechanical work, and models do it quickly and consistently.
Bidirectional translation between intent and policy language. Natural language to KQL or SPL; a business requirement to a draft policy. In the other direction, a pile of historical ACLs and scattered role descriptions translated into plain language, which surfaces redundancy and conflicts. Treat output as a draft: human review, validation in a test environment, staged rollout.
Graph query assistance. Helping write Cypher such as "find non-Tier-0 accounts reachable to Domain Admins within N hops," with the caveat that unbounded traversals can overwhelm the database, so scope and depth must be constrained.
Compliance mapping and documentation. Mapping ISO/IEC 27001, NIST SP 800-53, and SOC 2 controls to existing measures and producing a draft gap list; drafting access management policies, account lifecycle SOPs, audit and monthly report first drafts, and exercise scripts for scenarios such as Kerberoasting, pass-the-hash, token theft, and consent phishing.
Internal knowledge RAG. A question-answering bot over policy and SOP documents reduces repeated "who approves this access" traffic. A policy nobody consults functions, in practice, as a policy that does not exist.

This Rego fragment illustrates the shape of a "policy draft" — it turns a spoken rule (a read-only role may only touch the reports path; admins need MFA and an approval reference) into reviewable code. It is illustrative; a real policy needs a complete input contract and test cases:

package identity.authz

default allow = false

# Baseline: read-only role may access only the reports path
allow if {
    input.role == "readonly"
    startswith(input.resource, "reports/")
}

# Exception: admin access requires MFA and an approval reference, for later attribution
allow if {
    input.role == "admin"
    input.mfa == true
    input.approval_id != ""
}

The boundaries matter more than the capabilities, and four are non-negotiable.

Data egress. Account lists, entitlement matrices, raw logs, AD topology, collection output, and secrets stay out of public models. Use private deployment or an enterprise tier, apply de-identification and DLP upstream, and write "what data may enter a model" into policy.
Hallucination is a risk, not an annoyance. A single wrong condition in a generated policy can open a tenant-wide hole. Route every change through human review, staged rollout, and rollback.
AI does not make the final authorization decision. It supplies recommendations and context; a human approves and owns the outcome. AI output does not function as compliance evidence on its own.
AI agents must be governed as identities with explicit ownership and access controls. Identity and security vendors are extending their platforms to address agent registration, authorization, privilege management, and monitoring, although the available capabilities and maturity vary by product. Evaluate each vendor's current documentation for supported agent types, identity relationships, runtime controls, privilege expiry, audit records, and licensing before treating a capability as production-ready. AI agents can accumulate permissions through their own credentials, inherited access, delegated authority, or the tools they are allowed to invoke. Without explicit ownership and lifecycle controls, those permissions can become difficult to review or revoke. Non-human identity (NHI) and AI agent governance are likely to become increasingly important areas of identity security over the next few years.

On sequencing: start with low-risk, high-return uses (log queries, report triage, document drafting), stabilize them, and accumulate prompts and validation checklists. Move on to review and remediation assistance with a human signing off. Touch policy generation and runtime recommendations last. Pair this with an AI tool-use standard covering permitted data scope, approvals, and logging, and measure actual benefit through adoption rate, human-edit rate, and false-positive rate.

From Current State to Provable: An Ordered Action List

Everything discussed above has an implicit dependency order: risk cannot be judged without a baseline, controls cannot be proven without an evidence chain, and neither can be sustained without process quality. The ordering below reflects dependencies rather than a timeline; skipping ahead usually causes rework somewhere downstream.

First: establish the baseline and the evidence chain

Define authoritative sources for each identity domain and critical attribute, and document where identities originate, where groups are computed, and which system makes each access decision. Everything else builds on this foundation. Without clear ownership of identity data and a documented reconciliation process, entitlement records, review records, and audit evidence can diverge, leaving teams to resolve discrepancies manually.
Export sign-in and audit logs to long-term storage and add health monitoring for the pipeline. Harborline's investigation illustrates why this matters: expired logs may leave gaps that cannot be reconstructed afterward. Retention changes are not retroactive, so remediation after the fact is already too late, and silent pipeline breaks are typically found during an investigation.
Run a full account inventory and produce three lists: accounts without owners, shared accounts, and accounts not revoked after termination. These categories carry the highest risk concentration at the lowest cleanup cost. Clearing them reduces blast radius immediately and gives later metrics a credible starting point.
Use a protocol census to size the impact of blocking legacy authentication, and enable report-only first. Blocking outright locks out users and applications still on old protocols, and a single company-wide lockout is enough to lose internal support for the entire program. Quantifying the impact turns the decision from argument into arithmetic.
Stand up an exception register and log every known legacy issue (owner, compensating controls, review date). Legacy applications, CI/CD accounts, and vendor accounts will not disappear quickly. Registered, they become controlled items with owners, mitigations, and dates. Unregistered, they are the most damaging findings in an audit or a post-incident review.

Second: close structural risk and process quality gaps

Run a PingCastle baseline and record the score; run BloodHound and identify the shortest paths to Tier 0. The first provides a quantified, comparable starting point; the second provides attacker-reachable paths. Without a baseline, later improvement cannot be demonstrated. Without path analysis, remediation effort tends to land far from where an attacker would actually go.
Rank the top ten remediations by path length × blast radius ÷ cost, and assign owners and dates. AD assessments typically produce dozens or hundreds of findings; pursuing all of them consumes resources with diffuse benefit. This ordering cuts the shortest elevation paths with limited effort, and it is a prioritization executives can follow.
Give service accounts, API keys, and certificates their own register, inside rotation and review scope. These credentials often hold the broadest privileges, rotate least, and go unowned — svc-reporting is the specimen. Leaving them outside governance is an open path that requires no password.
Implement layered Conditional Access (all-user baseline / high-risk apps / admin-only / break-glass) and manage it as infrastructure. Layering gives different risk tiers different control strength, avoiding both a blanket rule that blocks the business and a single rule that treats admins and ordinary users identically. Managing it as code makes changes reviewable and reversible, reducing the blast radius of a console mistake.
Move certifications to risk-tiered review, add context for approvers, and start tracking the approve-all rate. Cedarline's 96% unexplained approvals show that process presence does not equal judgment. Risk ordering focuses attention, context gives approvers a basis, and the ratio detects when the review mechanism has stopped working.
Begin reporting JML automation rate, provisioning turnaround, and deprovisioning SLA attainment monthly. These measures provide useful evidence of identity lifecycle performance and can support audit preparation and customer questionnaires. The specific evidence required depends on the applicable control framework, contractual commitments, and assessment scope. Numbers first, then improvement; a trend line is what makes progress visible.

Third: make it a running state rather than a project

Re-run structural assessments quarterly and read the curve rather than the single result. One scan describes a moment; several quarters describe whether governance is improving or degrading, which is the most persuasive form for leadership.
Validate elevation paths semiannually with a red team or penetration test to confirm fixes actually hold. Paper checks tend to produce optimistic answers after configuration changes. Re-testing from an attacker's perspective exposes cases where a fix appeared complete but a bypass remained.
Review the exception register semiannually: retire what can be retired, refresh compensating controls for what cannot. A register that only grows becomes a list nobody reads. Periodic review drives real decommissioning and keeps long-lived exceptions controlled and monitored.
Write AI tool use into policy — permitted data scope, approvals, logging — and evaluate realized benefit quarterly. Without boundaries, the risks are sensitive data leaving the environment and unreviewed policy changes. Without measurement, the outcome is "we use it, and nobody knows whether it helps." Both need to be explicit for the capability to stay in the workflow.
Bring agents and non-human identities into the identity register and access reviews, managed to account standards from day one. Agent privileges frequently exceed their owner's scope, agents are created often, and they go unowned. Governing them after they become entrenched costs far more than governing them at creation.

This layer of security work has no dramatic victory moments. Its results usually show up as "nothing happened this time" and "we could reconstruct what happened." That is also why the standard for judging it stays plain: do the records match reality, have the reachable paths narrowed, is the evidence complete, and are anomalies detected in time. Get those four right and which vendor's product sits in the stack becomes a comparatively minor question.

References

Microsoft, continuously maintained Microsoft Entra data retention https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
Microsoft, 2026 Block legacy authentication with Conditional Access https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication
SpecterOps, continuously maintained BloodHound Documentation https://bloodhound.specterops.io/
National Institute of Standards and Technology (NIST), 2026 New Concept Paper on Identity and Authority of Software Agents https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents

Menu