IGA best practices are established, but often ignored

At a glance

What this is: This is an argument that Identity Governance and Administration already has proven best practices, and the key finding is that organisations fail when they abandon them for flexibility and speed.

Why it matters: It matters because IAM, IGA, and compliance teams need governance models they can defend, automate, and audit across human and non-human identities without accumulating implementation debt.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Fischer Identity's blog on why IGA best practices already exist

Context

Identity Governance and Administration works when identity data is authoritative, access rules are policy-driven, and certification is repeatable. The article argues that these conditions are not aspirational best practices but established operating patterns that reduce risk and make compliance auditable. That framing matters because IGA programmes usually fail in the gap between design intent and implementation discipline.

For identity teams, the central issue is not whether standards exist. It is whether the programme uses configuration, lifecycle automation, and access governance in a way that survives scale, audit, and organisational change. That is as true for human identities as it is for service accounts and other non-human identities, where governance debt accumulates faster and visibility is usually weaker.

Key questions

Q: How should teams build an IGA programme that survives scale and audits?

A: Anchor governance in authoritative source data, policy-driven access rules, and repeatable certification. If the programme depends on manual fixes or custom scripts, it will eventually fail an audit or break during change. The goal is not more complexity, but control logic that stays visible, testable, and reproducible as the environment grows.

Q: Why do identity governance programmes break when teams rely on flexibility?

A: Flexibility often means exceptions, local overrides, and code paths that nobody fully owns. Those shortcuts create conflicting identity state, fragile provisioning, and unclear audit trails. Once the system can no longer explain why access exists, governance has already weakened. A durable IGA model limits variation and keeps policy enforcement explicit.

Q: What do teams get wrong about access certification?

A: Teams often treat certification as proof that access is safe, when it is really only a decision process. The quality of the outcome depends on the context given to reviewers, including role, activity, and ownership. Without that context, approvals can simply preserve inherited access and outdated entitlements.

Q: How do human and non-human identity governance models differ in practice?

A: The core control logic is similar, but non-human identities change faster, scale more widely, and are easier to overlook. That means lifecycle automation, visibility, and revocation discipline must be tighter for service accounts, API keys, and workload identities. Treating them as an exception class creates governance blind spots.

Technical breakdown

Why authoritative source alignment is the foundation of IGA

Identity governance becomes unstable when the system of record is ambiguous. Authoritative source alignment means the IGA platform derives identity state from trusted upstream systems such as HR, student records, ERP, or CRM, rather than from manual updates or disconnected local records. Without that alignment, provisioning and certification are built on conflicting truths, which creates duplicate identities, stale entitlements, and audit exceptions. The technical point is simple: governance cannot be stronger than the data it trusts.

Practical implication: map every identity population to a declared source of truth before expanding lifecycle automation or access reviews.

How configuration-driven governance reduces implementation debt

A configuration-driven IGA model uses policy, workflow, and connector settings instead of custom code to express access rules. That matters because custom scripts often work until upgrades, exceptions, or new integrations expose hidden dependencies. Configuration-based design preserves portability, makes control logic visible to auditors, and lowers the chance that business rules become trapped in brittle code. In practice, this is the difference between a governable platform and one that only works when the original implementer is still available.

Practical implication: eliminate script-heavy control logic where policy or workflow configuration can express the same requirement.

Why continuous certification matters more than periodic cleanup

Periodic access reviews only work if identity state changes slowly enough for reviewers to catch it. Modern IGA environments do not behave that way. Roles change, privileges accumulate, and entitlements drift between review cycles, which is why continuous attestation and event-driven governance are becoming more relevant than annual or quarterly clean-up exercises. This does not replace certification; it changes the timing and evidence model so auditors can see current state rather than historical snapshots.

Practical implication: shorten the gap between access change and review evidence, especially for high-risk roles and privileged accounts.

Threat narrative

Attacker objective: The end state is not simply access abuse but governance failure that leaves the organisation unable to prove who should have access, who actually has it, and why.

1. Entry occurs when organisations adopt fragile customisations or inconsistent governance logic that bypasses authoritative identity data.
2. Escalation follows when stale entitlements, conflicting sources of truth, or manual exceptions accumulate beyond what review cycles can catch.
3. Impact is control drift, audit failure, and inconsistent provisioning or deprovisioning across the identity estate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IGA best practices are real, but programme discipline is the differentiator. The article is correct to reject the idea that identity governance is a blank-slate discipline. NIST, ISO, and community guidance have already established the core control pattern: authoritative data, policy-based access, attestation, and auditability. The failure is rarely conceptual. It is operational, where teams allow flexibility, custom code, or local exceptions to override the control model. Practitioners should treat maturity as adherence to proven governance mechanics, not as invention.

Configuration-driven governance is the only sustainable answer to identity complexity. Custom scripts and bespoke workflow logic create hidden dependencies that usually surface during upgrades, audits, or integration changes. That is a governance problem, not just a technical inconvenience, because the organisation can no longer explain or reproduce its own control state. For IGA programmes, the practical conclusion is that control logic must remain visible, portable, and reviewable.

Continuous identity state is replacing periodic governance as the real control benchmark. Periodic certification still has a role, but it no longer captures how fast identities change in cloud and hybrid estates. When roles, privileges, and non-human credentials shift daily, the real question is whether governance can produce evidence at the same speed as change. Practitioners should stop treating review cadence as the control itself and measure whether the programme maintains current, defensible identity state.

NHI governance and human IGA are converging on the same discipline, but at different speeds. The article speaks mainly to classic IGA, yet the same principles now govern service accounts, API keys, and workload identities. The difference is that non-human identities accumulate faster and are less visible, which makes lifecycle automation and attestation even more consequential. Teams should align their governance model across human and non-human populations instead of maintaining separate control philosophies.

Least privilege only works when policy is expressed where access is actually decided. Policy-based access control is not a slogan, it is the mechanism that keeps identity logic from becoming unmanageable as systems grow. If access rules live in code, spreadsheets, or manual exceptions, least privilege becomes unverifiable. Practitioners should require control expression at the governance layer, not in scattered implementation artefacts.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• For lifecycle-specific controls, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline.

What this signals

Continuous governance is becoming the practical baseline for identity programmes. Teams that still depend on periodic reviews and exception handling will keep discovering drift after the fact, especially in hybrid environments where access changes constantly. The better operating model is to treat identity state as something that must be continuously computed and evidenced, not periodically reconstructed.

NHI lifecycle discipline is now part of mainstream IGA maturity. Service accounts, API keys, and workload identities no longer sit outside governance just because they are not human. When identity estates expand faster than oversight, lifecycle management becomes the difference between controlled access and accumulated exposure.

With NHIs outnumbering human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs, governance teams need one control model that spans both identity classes without splitting policy logic.

For practitioners

• Standardise authoritative sources Declare which upstream systems own identity truth for employees, students, contractors, service accounts, and other governed populations. Reconcile provisioning logic against those sources before expanding automation.
• Remove custom code from governance paths Move access rules, workflow branching, and connector logic into configuration wherever possible so upgrades do not break hidden dependencies or audit evidence.
• Shorten certification latency Tie access reviews to changes in role, entitlement, or employment state so reviewers assess current identity state rather than stale snapshots from a quarterly cycle.
• Extend governance to non-human identities Apply the same lifecycle, attestation, and deprovisioning discipline to service accounts, API keys, and workload identities that you already expect for human access.

Key takeaways

• IGA best practices are not missing, but they are often abandoned when organisations choose convenience over discipline.
• Authoritative data, configuration-driven control, and continuous attestation are the practical foundations of auditable identity governance.
• The same governance model must now extend cleanly from human identities to service accounts and other non-human identities.

Key terms

• Authoritative Identity Source: An authoritative identity source is the system trusted to define who or what should have access. It is usually the HR system for workforce identities or another governed directory for technical identities, and its accuracy determines whether automation strengthens or weakens control.
• Certification: A certification is a structured access review campaign that records a reviewer’s decision about whether an identity record remains correct and necessary. In regulated environments, it must produce traceable evidence, require a named owner, and preserve the decision in an immutable audit trail.
• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.
• Identity State: Identity state is the live condition of an account, token, certificate, or permission set at a given moment. It matters because a task can be complete while the real access remains active, stale, or overprivileged. Security teams should validate identity state rather than relying only on process completion.

What's in the full article

Fischer Identity's full blog covers the operational detail this post intentionally leaves for the source:

• The article expands on configuration-first design choices that reduce custom code in identity workflows.
• It outlines how the vendor maps authoritative sources to governance rules across HR, SIS, ERP, and CRM systems.
• It shows how policy-based access models such as RBAC, ABAC, and PBAC are expressed in the platform.
• It describes the vendor's implementation claims around fixed-fee deployments and auditability at scale.

👉 Fischer Identity's full post covers the governance framework, implementation model, and auditability claims in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.