Identity Security Programme Guide: Operating Model

Identity security is no longer a set of separate projects for SSO, access reviews and password vaults. It is a programme that spans employees, contractors, customers, service accounts, workloads, API keys and AI agents, across dozens of platforms and teams. Many organisations still run these as disconnected efforts with different owners, budgets and tools, which leaves gaps exactly where attackers look: the service token nobody rotated, the account without MFA, the agent running on a developer's credentials. This guide sets out how to structure an identity security programme: scope, operating model, roles and responsibilities, roadmap, funding, governance and the metrics that show it is working. It maps the programme to NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022 Annex A, CIS Controls v8.1 and the OWASP Non-Human Identities and Agentic Top 10 lists. It is written for CISOs, identity leads and programme managers who need to turn a collection of identity projects into one accountable capability.

Key takeaways

Scope all identity types: workforce, privileged, customer, non-human and AI agent identities belong in one programme with one inventory and one set of standards.
Name an accountable owner for every activity: NIST CSF 2.0 expects roles, responsibilities and authorities to be "established, communicated, understood, and enforced" (GV.RR-02), and that includes identities created by platform and development teams.
Build the roadmap from risk and maturity: assess a current profile, agree a target profile and sequence the gaps, rather than starting from product purchases.
Fund a capability, not a project: platforms fail without the people to run them and the budget to integrate applications.
Report outcomes, not activity: a small, stable set of measures tied to risk, rolled up into the enterprise risk register, is what leadership can act on.

Programme scope

A programme is defined first by what it covers. The most common scoping error is to treat identity security as workforce single sign-on and access reviews, and to leave service accounts, secrets and AI agents to whichever platform team happens to create them. NIST CSF 2.0 makes no such distinction: its first identity outcome, PR.AA-01, reads "Identities and credentials for authorized users, services, and hardware are managed by the organization". Services and hardware are in scope by definition.

Domain	Includes	Related guides
Workforce identity	SSO, MFA, joiner-mover-leaver lifecycle, access reviews	Workforce Identity Security Guide
Privileged access	Admin accounts, just-in-time access, session management, break-glass	Privileged Access Management Guide
Identity governance	Roles, requests, certifications, segregation of duties	IAM and IGA Basics
Non-human identity	Service accounts, API keys, secrets, certificates, workload identity	Ultimate Guide to Non-Human Identities
AI agent identity	Agent registration, delegation, authorisation, monitoring	Agentic AI Identity Guide
Customer identity	Registration, authentication, account takeover, consent	Customer IAM (CIAM) Guide
Third-party access	Suppliers, contractors, partner integrations and their credentials	Third-Party Access Guide
Identity threat detection	ITDR, posture management, visibility	ITDR Guide, ISPM Guide

Write the scope down in a programme charter: which identity types, which environments (on-premises directories, cloud tenants, SaaS, CI/CD, AI platforms), which business units and which exclusions. Exclusions should be explicit and time-limited.

Operating model

The operating model answers who sets policy, who builds and runs platforms, who owns each identity and who checks that controls work. NIST SP 800-53 Rev. 5 places this at the top of the organisation: PM-2 calls for a senior information security officer "with the mission and resources to coordinate, develop, implement, and maintain an organization-wide information security program", and PM-29 adds a senior accountable official for risk management and a risk executive function. Identity is one of the largest parts of that programme, and it needs the same clarity.

Roles and responsibilities

Activity	CISO / security	IAM team	Platform and cloud teams	Application and identity owners	Risk, audit, compliance
Identity policy and standards	Accountable	Responsible	Consulted	Informed	Consulted
Identity platforms (IdP, IGA, PAM, secrets)	Informed	Accountable and responsible	Consulted	Informed	Informed
Workload and cloud identity implementation	Consulted	Consulted	Accountable and responsible	Consulted	Informed
Access approval and review	Informed	Responsible (process)	Informed	Accountable	Consulted
NHI and agent ownership	Informed	Responsible (process)	Responsible	Accountable	Informed
Identity threat detection and response	Accountable	Consulted	Consulted	Informed	Informed
Control assurance and audit	Consulted	Consulted	Consulted	Consulted	Accountable

Adapt the model to your organisation; the key is that every activity has exactly one accountable owner, and that owners of non-human identities are named people or teams, not "the platform". See the NHI Ownership Guide.

Centralised, federated or hybrid

Centralised: one IAM team builds and operates everything. Consistent, but it becomes a bottleneck as cloud, SaaS and agent platforms multiply.
Federated: business and platform teams implement identity controls against central standards. Scales better, but needs strong governance and a shared inventory, or standards drift.
Hybrid (common): the central team owns policy, the identity provider, governance and privileged access platforms; platform teams own workload identity and NHIs in their domains against central standards; application owners own access decisions.

Skills and capacity

A programme needs identity architects, engineers who integrate applications and automate lifecycles, analysts who run reviews and exceptions, and people who work with developers on secrets and workload identity (SP 800-53 PM-13, Security and Privacy Workforce). Where capacity is short, prioritise integration and automation: manual processes do not scale to the number of non-human identities most estates hold.

Bringing NHIs and AI agents into the programme

Non-human identities and AI agents are where programmes most often lack an owner, a standard and a lifecycle. The OWASP Non-Human Identities Top 10 (2025) lists the failures that follow: improper offboarding (NHI1), secret leakage (NHI2), overprivileged NHIs (NHI5), long-lived secrets (NHI7), NHI reuse (NHI9) and human use of NHIs (NHI10), which OWASP notes causes a "lack of auditing and accountability due to indistinguishable activity between humans and automation".

AI agents add delegation. The OWASP Top 10 for Agentic Applications for 2026 describes Identity and Privilege Abuse (ASI03) as arising from "the architectural mismatch between user-centric identity systems and agentic design", and states that without a distinct, governed identity "an agent operates in an attribution gap that makes enforcing true least privilege impossible". Its mitigations are programme decisions as much as technical ones:

Per-agent identities: each agent has its own identity and short-lived credentials, not a shared or borrowed one.
Task-scoped, time-bound permissions: short-lived, narrowly scoped tokens per task, capped by permission boundaries.
Human approval: human-in-the-loop approval for high-privilege or irreversible actions.
Delegation monitoring: detect when an agent gains new permissions indirectly through delegation chains.

In programme terms this means agents go through the same registration, ownership, review and offboarding as other identities, with a named business owner. Discovery comes first. See the Shadow AI Discovery Guide.

Building the roadmap

NIST CSF 2.0 gives a simple structure for a roadmap. A Current Profile "specifies the Core outcomes that an organization is currently achieving (or attempting to achieve)", and a Target Profile "specifies the desired outcomes that an organization has selected and prioritized". The roadmap is the plan to close the gap between the two. CISA's Zero Trust Maturity Model makes the same point for zero trust: assess current systems, personnel and processes "before investing in zero trust capabilities", then move through its Traditional, Initial, Advanced and Optimal stages.

Assess: maturity across domains, current risks, audit findings and incidents, and an honest inventory of identities by type. See the Identity Security Maturity Model.
Prioritise by risk: typically phishing-resistant MFA for administrators, privileged access reduction, NHI discovery and secrets hygiene, leaver processes and agent governance.
Sequence dependencies: inventory and ownership before governance; authoritative sources (HR, the CMDB, cloud accounts) before automation; a secrets platform before mass rotation.
Plan in phases: quick wins in the first quarter, foundational capabilities over the first year, optimisation afterwards.
Define outcomes: each initiative has a measurable risk reduction target and an owner. See the Identity Security Metrics Guide.

Use the CISA identity pillar's governance function as a test of progress. At the Traditional stage, identity policies are enforced "via static technical mechanisms and manual review"; at Optimal, the organisation "implements and fully automates enterprise-wide identity policies for all users and entities across all systems with continuous enforcement and dynamic updates". The roadmap should say which step each initiative moves.

Implementation roadmap

A starting sequence for a programme being formalised; adjust the timing to your size and assessment findings, as the order matters more than the dates.

Phase	Programme and governance	Controls and platforms	Exit criteria
First 30 days	Appoint the programme owner and steering group; agree the charter and scope across all identity types; start the identity risk register	Baseline inventory of privileged accounts, service accounts and known AI agents; confirm MFA coverage for administrative and remote access	Charter signed; owners named for each domain; baseline counts recorded
Days 31 to 90	Complete the maturity assessment and agree the target profile; publish identity standards and the exceptions process; agree the metric set	Remove or disable dormant accounts; assign owners to service accounts; bring secrets into a managed store for the highest-risk systems; register agents in use	Approved roadmap and budget; first metrics report to the steering group
Days 91 to 180	Quarterly reporting to the risk committee; first board briefing; review of exceptions and their expiry	Phishing-resistant MFA for administrators; just-in-time privileged access for priority systems; automated leaver processing from HR; rotation and expiry for long-lived secrets; per-agent identities for new agent deployments	Metrics trending in the right direction; open high risks have dated treatment plans
Beyond 180 days	Annual review of strategy and target profile; refresh of the operating model as platforms change	Extend automation across remaining applications; workload identity federation in place of static keys; continuous posture and threat detection across identity platforms	Movement towards the Advanced or Optimal stage in the CISA identity pillar

Funding

SP 800-53 PM-3 expects organisations to "include the resources needed to implement the information security and privacy programs in capital planning and investment requests". CSF 2.0 makes the same point as an outcome: GV.RR-03 reads "Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies". For identity, that means planning three cost lines, not one.

Platforms: identity provider, governance, privileged access, secrets management and detection tooling, with licence growth for non-human identities and agents, which often outnumber people.
People: fund the engineers and analysts to run the platforms. Tooling without operating capacity fails.
Integration: allocate budget for connecting applications, cleaning authoritative data and migrating credentials. This is often the largest hidden cost and the reason roadmaps slip.

Build the case on risk reduction, audit and regulatory requirements, operational efficiency and enablement of business initiatives such as AI adoption. Tie each funding request to a risk in the register and a measure that will show it moving. See the Business Case Guide.

Governance

Governance keeps the programme aligned with the organisation's risk appetite and keeps owners to their commitments. CSF 2.0 covers this in its Govern function: policy is "established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced" (GV.PO-01), and oversight expects that "Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed" (GV.OV-03).

Forums and reporting

Identity steering group: security, IT, platform, development, business and risk representation, deciding priorities and resolving ownership disputes.
Risk committee: quarterly reporting on identity risks, metrics and exceptions. See the Board Cyber Risk Reporting Guide.
Board: periodic briefings in business risk terms, with a few measures and the decisions needed.

Standards and exceptions

Publish identity standards (authentication strength by risk, credential lifetimes, review frequencies, ownership rules for NHIs and agents) under the wider policy set. See the Security Policy Framework Guide. Every exception needs an owner, a compensating control and an expiry date, and expired exceptions should be reported, not silently renewed.

Risk registers

NIST IR 8286 Rev. 1 describes the use of risk registers to set out cybersecurity risk and "the value of rolling up measures of risk that are usually addressed at lower system and organizational levels to the broader enterprise level". Record identity risks (for example, unowned service accounts or agents with standing privileged access) in a register that feeds enterprise risk management, so that CSF outcome GV.RM-03, cybersecurity risk management "included in enterprise risk management processes", is met for identity. See the Risk Register Template.

Regulatory alignment

CSF GV.OC-03 expects legal, regulatory and contractual requirements to be "understood and managed". Map identity obligations once and reuse the evidence across audits. See the Identity Security Regulatory Map.

Metrics that show progress

NIST SP 800-55 Vol. 1 warns that "Poorly selected quantitative metrics can undermine the overall quality of reporting and erode confidence in the work product", and advises that "less is often more". Vol. 2 adds that ensuring "each stakeholder is responsible for as few measures as possible" makes the measures meaningful, and that obsolete measures are phased out as targets are reached. SP 800-53 PM-6 asks organisations to "Develop, monitor, and report on the results of information security and privacy measures of performance". Start with a handful of outcome measures like these.

Metric	What it shows	Target direction
Identities with a named accountable owner, by type (human, NHI, agent)	Whether the operating model reaches every identity	Up, towards full coverage
Privileged accounts protected by phishing-resistant MFA	Resistance to credential phishing for the most damaging accounts	Up
Standing privileged access (accounts with permanent admin rights)	Progress towards just-in-time and zero standing privilege	Down
Time from HR leaver event to access removal	Lifecycle automation and leaver risk	Down
Secrets older than the policy lifetime, and secrets found in code or tickets	Exposure to long-lived and leaked credentials (OWASP NHI2, NHI7)	Down
Dormant accounts and unused NHIs still enabled	Offboarding effectiveness (OWASP NHI1)	Down
AI agents registered with their own identity and owner, as a share of agents discovered	Whether agent governance keeps pace with adoption	Up
Access removed as a result of reviews	Whether reviews change access, rather than rubber-stamping it	Up at first, then stable
Open identity exceptions past expiry	Discipline of the standards and exceptions process	Down

Report each measure against a target and a trend, and keep the definitions stable so quarter-to-quarter comparisons hold. SP 800-55 Vol. 1 notes that keeping metrics consistent over time lets organisations "evaluate long-term trends and expected ranges".

Framework mapping

The mapping below links programme areas to control references checked against the framework texts. ISO/IEC 27001:2022 Annex A names are taken from published Annex A listings; CIS references are CIS Controls v8.1 Safeguards.

Programme area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP NHI / Agentic
Programme leadership and plan	GV.RR-01, GV.RM-01	PM-1, PM-2, PM-29	5.1 Policies for information security, 5.4 Management responsibilities	n/a	n/a
Roles, responsibilities and ownership	GV.RR-02	PM-2, PM-13	5.2 Information security roles and responsibilities	5.5 (service account inventory)	NHI10, ASI03
Funding and resources	GV.RR-03	PM-3	5.4 Management responsibilities	n/a	n/a
Policy, standards and exceptions	GV.PO-01, GV.PO-02	AC-1, PM-9	5.1 Policies for information security, 5.36 Compliance with policies, rules and standards	n/a	n/a
Risk register and ERM integration	GV.RM-03, GV.RM-06, ID.RA-05	PM-9, PM-28, RA-3, PM-4	n/a	n/a	n/a
Identity inventory and lifecycle	PR.AA-01, ID.AM-02	AC-2, AC-2(3), IA-4, CM-8	5.16 Identity management, 5.18 Access rights	5.1, 5.3, 5.5, 6.1, 6.2	NHI1, NHI9
Authentication and credentials	PR.AA-03	IA-2, IA-5, IA-9	5.17 Authentication information, 8.5 Secure authentication	6.3, 6.4, 6.5	NHI2, NHI4, NHI7
Least privilege and privileged access	PR.AA-05	AC-6, AC-6(5)	5.15 Access control, 8.2 Privileged access rights, 5.3 Segregation of duties	5.4, 6.8	NHI5, ASI03
Supplier and third-party identities	GV.SC-01	PM-30, SR-6	5.19 Information security in supplier relationships	n/a	NHI3
Monitoring and detection	DE.CM-03	AU-6, SI-4, CA-7	8.15 Logging, 8.16 Monitoring activities	n/a	ASI03 (delegation monitoring)
Measurement and improvement	GV.OV-03, ID.IM-01	PM-6, PM-31	5.35 Independent review of information security	n/a	n/a

For a wider method of mapping one control set to several frameworks, see the Control Mapping Guide.

Common failure patterns

Programme scoped to workforce only. NHIs and agents are left with no owner and no standard. Cloudflare's account of its Thanksgiving 2023 incident says it "failed to rotate one service token and three service accounts (out of thousands)" after the Okta compromise, because "mistakenly it was believed they were unused". A programme that inventories and owns service credentials makes that belief testable. See the Cloudflare Thanksgiving Breach 2023.
Standards without enforcement. MFA and rotation policies exist on paper but not on every account. In the Snowflake customer intrusions, Mandiant reported that affected instances "did not require multi-factor authentication and in many cases, the credentials had not been rotated for as long as four years". See the Snowflake Breach 2024.
Tool-led roadmaps. Platforms are bought before processes, owners and data sources are defined, so adoption stalls.
No accountable owner for engineering-created identities. Service accounts, CI/CD credentials and agents created by platform and development teams sit outside governance.
Activity metrics. Reporting reviews completed rather than access removed or risk reduced, which hides rubber-stamping.
Unfunded operations. Capital for platforms with no budget for the people who run them or the integration work, so the platform covers a fraction of the estate.
Exceptions that never expire. Temporary waivers become permanent, and the risk they carry never reaches the register or the risk committee.

Practitioner checklist

Define programme scope across workforce, privileged, customer, third-party, non-human and AI agent identity in a signed charter.
Appoint a programme owner and a steering group with security, platform, development, business and risk representation.
Agree an operating model with one accountable owner for every activity and a named owner for every NHI and agent.
Assess maturity, record a current profile and agree a target profile.
Build a risk-prioritised, phased roadmap with dependencies and exit criteria.
Fund platforms, people and integration effort as separate lines.
Publish identity standards and an exceptions process with owners and expiry dates.
Bring AI agents into the lifecycle: registration, own identity, scoped short-lived credentials, review and offboarding.
Record identity risks in a register that rolls up to enterprise risk management.
Report a small, stable set of outcome metrics to the steering group, risk committee and board.
Map controls once to CSF 2.0, SP 800-53, ISO/IEC 27001 and CIS, and reuse the evidence.

How NHI Mgmt Group can help

We support programme initiation, maturity assessments, roadmaps and business cases for identity, NHI and agentic AI security. Browse the NHI and AI products directory, build team skills through NHI training, or contact us to discuss your programme.

Identity Security Programme Guide