A few things that frame the scale:

• The organization was able to reduce SoD conflicts at go-live by about 85% compared to the initial design baseline, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.

A question worth separating out:

Q: When should organisations treat privileged access as a release gate in ERP programmes?

A: Privileged access should be treated as a release gate before production cutover, not as a post-launch cleanup item. Teams need evidence that emergency access is monitored, approvals are documented, and roles are aligned to risk tolerance before they allow go-live.

👉 Read our full editorial: ERP modernization exposes access governance gaps in NHI controls

A few things that frame the scale:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.

A question worth separating out:

Q: How do security teams respond when AI identity governance is already deficient?

A: First, contain the highest-risk identities by reviewing standing access, removing unnecessary privileges, and forcing ownership assignment for every NHI. Then establish discovery and certification workflows so the same problem does not reappear. If AI is already in production, the right response is staged reduction of exposure, not a blanket freeze on adoption.

👉 Read our full editorial: AI identity risk is exposing the NHI visibility gap in enterprise IAM

A few things that frame the scale:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirming one and 26% suspecting one.

A question worth separating out:

Q: What should teams do in the first 24 to 72 hours after a trusted identity is abused?

A: Teams should revoke the compromised identity, invalidate active sessions and tokens, review downstream trust relationships, and isolate any control plane that could still be used for destructive actions. They should then identify whether the identity was human, machine, or third-party owned, because the containment steps and recovery order differ. The first goal is to stop inherited trust from spreading further.

👉 Read our full editorial: Identity supply chains are under siege as trust cascades downstream

A few things that frame the scale:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why pipeline exposure keeps recurring even in mature programmes.

A question worth separating out:

Q: What should teams do in the first 24 to 72 hours after suspected package compromise?

A: Teams should isolate affected hosts, preserve forensic evidence, rotate exposed credentials, and inspect repositories for unauthorized workflow or package changes. They should also review internal mirrors and caches, because malicious versions may persist there after public removal. The goal is to stop reuse of stolen identities before the attacker expands access.

👉 Read our full editorial: SAP npm supply chain compromise exposes dev and CI/CD credentials

A few things that frame the scale:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, according to The 2026 Infrastructure Identity Survey.

A question worth separating out:

Q: How do organisations prepare for the EU AI Act without slowing AI adoption?

A: They should start with visibility, then classify use cases, then enforce access and logging. That sequence lets teams keep moving while reducing surprise exposure. The objective is not to stop adoption, but to make every AI workflow explainable, owned, and reviewable.

👉 Read our full editorial: EU AI Act turns AI governance into a control challenge

A few things that frame the scale:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

A question worth separating out:

Q: How do organisations know if zero trust controls are actually working?

A: They know the controls are working when they can inventory privileged identities, prove access is time-bound, and show that rotation and revocation happen on schedule. A healthy programme also has few manual exceptions and low workflow friction, because recurring bypasses are a sign that policy and operations are out of sync.

👉 Read our full editorial: Federal zero trust execution is stalling on NHI governance gaps

TL;DR: ERP implementations often copy legacy access, rely on broad roles, and defer compliance work until late-stage testing, which increases SoD conflicts and audit findings, according to Delinea. Treating security as a design input instead of a phase-two task is now the difference between controlled go-live and expensive remediation.

NHIMG editorial — based on content published by Delinea: Include security and compliance from the start of ERP implementations

By the numbers:

• The organization was able to reduce SoD conflicts at go-live by about 85% compared to the initial design baseline.
• The organization also saved an estimated 60-70% in post-go-live remediation efforts.

Questions worth separating out

Q: How should security teams implement ERP access governance before go-live?

A: Start with a defined access governance framework that assigns ownership, approval paths, and provisioning rules before implementation is complete.

Q: Why do ERP projects create hidden NHI risk?

A: ERP projects create hidden NHI risk because batch jobs, integration accounts, and emergency access often receive broad or poorly attributed permissions.

Q: What breaks when organisations copy legacy access into a new ERP system?

A: Copying legacy access preserves old privilege patterns, including broad roles and unresolved segregation of duties conflicts.

Practitioner guidance

• Map every ERP identity type before design freezes Inventory human roles, service accounts, batch jobs, emergency access, and integration credentials, then assign an owner and business purpose to each identity.
• Design roles from process boundaries, not from legacy templates Build RBAC around end-to-end business processes and separate configuration, operations, and monitoring duties so copied access does not reintroduce SoD conflicts.
• Test access controls during UAT and sprint reviews Validate provisioning flows, privileged access, and compensating controls before cutover so role defects are found while remediation is still cheap.

That means the control priority is not just migration success, but how much inherited access is intentionally removed before launch?

👉 Read Delinea’s guidance on security and compliance in ERP implementations →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Delinea reports that 87% of organisations say their identity security posture is prepared for AI, yet 46% admit their AI identity governance is deficient and 53% regularly encounter unauthorized AI tools or agents accessing company systems. The gap is not visibility alone, but the mismatch between autonomous NHI behaviour and legacy IAM controls that still assume human-paced access review.

NHIMG editorial — based on content published by Delinea: The hidden risk of non-human identities in AI adoption

By the numbers:

• 87% of organizations say their identity security posture is prepared.
• 46% of those surveyed admitting that their AI identity governance is deficient.
• 53% of surveyed organizations regularly encounter unauthorized AI tools and agents accessing company systems.

Questions worth separating out

Q: How should security teams implement least privilege for AI agents and NHIs?

A: Start by treating AI agents as a separate identity class with explicit ownership, purpose, and lifecycle records.

Q: Why do NHIs complicate zero trust architecture in practice?

A: NHIs complicate zero trust architecture because they authenticate and act at machine speed, often without the human checkpoints that zero trust programs assume.

Q: What breaks when organisations cannot see their non-human identities?

A: When NHIs are invisible, least privilege, credential rotation, and access review all become incomplete.

Practitioner guidance

• Implement continuous discovery for machine identities Inventory service accounts, API keys, tokens, certificates, AI agents, and shadow AI tools across cloud and hybrid environments.
• Reduce standing privilege for autonomous identities Classify every persistent entitlement held by NHIs and AI agents, then replace it with just-in-time access where operationally possible.
• Enforce access certification for NHIs Run regular access reviews on machine identities with the same rigor used for human access.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the control model is already out of balance?

👉 Read Delinea's analysis of hidden NHI risk in AI adoption →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: March’s breach pattern showed that attackers are compromising trusted identities, not perimeter controls, and then using legitimate access to move downstream, according to Delinea Labs’ April 2026 Threat Outlook. The result is a governance problem, not just an authentication problem, because identity can become the weapon once trust is inherited across tenants, partners, and automation.

NHIMG editorial — based on content published by Delinea: Identity supply chains are under siege

By the numbers:

• The European Commission was among the targets when a compromised Trivy development pipeline led to approximately 340 GB of data being stolen.
• In March, 5,236 CVEs were disclosed across the industry, including 519 identity-related vulnerabilities.

Questions worth separating out

Q: How should security teams handle trust assumptions in identity supply chains?

A: Security teams should assume that any trusted upstream identity can become a downstream entry point if its permissions are not continuously verified.

Q: Why do service accounts and other non-human identities increase breach impact?

A: Service accounts and other non-human identities increase breach impact because they often carry broad, persistent access and bypass interactive controls like MFA.

Q: What breaks when administrative identity governance is weak?

A: When administrative identity governance is weak, one compromised account can change policies, wipe devices, approve access, or unlock whole environments without a second control layer.

Practitioner guidance

• Map downstream trust relationships Inventory where admin accounts, SSO sessions, cloud roles, and service accounts can operate across tenants, vendors, and automation workflows.
• Enforce just-in-time control for high-impact actions Apply just-in-time approval to destructive operations such as device wipes, policy changes, key rotation, and role assignment.
• Govern non-human identities as identities Assign owners, set expiry, rotate credentials, and review entitlements for service accounts, API keys, and automation tokens on a recurring schedule.

Teams that can model those links will be better positioned to stop trust cascade before it becomes incident response?

👉 Read Delinea's analysis of identity supply chain compromise patterns →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Malicious npm packages used in SAP CAP and MTA build workflows executed during dependency installation, targeting developer machines, CI/CD runners, build containers, and repositories for secrets, tokens, and cloud credentials, according to Pathlock and SAP Security Note 3747787. The incident shows that SAP security now has to cover the software supply chain that builds and deploys extensions, not just the application stack.

NHIMG editorial — based on content published by Pathlock: SAP npm supply chain incident affecting CAP and MTA build workflows

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

Questions worth separating out

Q: How should security teams contain a supply chain incident in build environments?

A: Containment starts with identifying every runner, workstation, cache, and container image that resolved the affected package versions.

Q: Why do build pipelines create such a large NHI risk?

A: Build pipelines often hold service accounts, deployment tokens, registry credentials, and cloud keys that allow software to move from code to production.

Q: What breaks when secrets are stored on CI runners and developer machines?

A: Secrets on shared or long-lived runners break the assumption that installation is a harmless administrative step.

Practitioner guidance

• Map all affected build and developer hosts Identify every workstation, CI runner, container image, and cache that installed the malicious package versions or resolved them through lockfiles, mirrors, or dependency updates.
• Rotate credentials reachable from the blast radius Revoke and recreate GitHub tokens, npm tokens, cloud keys, SAP BTP service keys, Kubernetes credentials, and any deployment secrets present on exposed hosts.
• Review repository and workflow tampering Search for unauthorized repositories, branch pushes, workflow edits, .vscode tasks, and .claude files that may indicate persistence or propagation attempts.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader pattern is clear: machine-readable trust material is proliferating faster than most governance programmes can track it?

👉 Read Pathlock's analysis of the SAP npm supply chain incident →

Explore further

View Full Forum →  |  NHI Foundation Course →