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 →

TL;DR: The EU AI Act applies to organisations that place AI systems or general-purpose AI models on the EU market, put them into service, or use them in the EU, and it sets staggered obligations from February 2025 through August 2027, according to Delinea. Policy alone is not enough; identity visibility, access control, and auditability now determine whether AI can be governed in motion.

NHIMG editorial — based on content published by Delinea: EU and AI, what you need to know about AI regulations

By the numbers:

• 56% of organizations reported that shadow AI incidents are occurring on a monthly basis.
• The EU AI Act entered into force on August 1, 2024, with most of the broader regime applying from August 2, 2026.
• The Regulation sets thresholds up to €35 million or 7% of worldwide annual turnover for certain infringements.

Questions worth separating out

Q: How should security teams govern AI systems that can act on sensitive data?

A: Security teams should treat AI systems as non-human identities with scoped access, named ownership, and full logging.

Q: Why do AI systems complicate IAM and NHI governance?

A: AI systems complicate IAM and NHI governance because they blur the line between user, workload, and automated actor.

Q: What breaks when AI agents are not inventoried or classified?

A: When AI agents are not inventoried or classified, organisations lose the ability to assign risk, apply the right obligations, and prove control to auditors.

Practitioner guidance

• Inventory every AI touchpoint Map internal assistants, embedded SaaS features, developer tools, and third-party models to business owner, data scope, and regulatory role.
• Bind each AI workflow to a named identity Use scoped non-human identities, temporary tokens, and identity-context logging so every AI action can be traced back to an owner and purpose.
• Classify use cases before you classify tools Start with the business function, the sensitivity of the data, and the consequence of failure, then decide whether the AI activity falls into transparency, deployer, or high-risk obligations.

Teams should prepare for AI identities to be reviewed like privileged workloads, not like policy exceptions?

👉 Read Delinea's analysis of the EU AI Act and AI governance controls →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Federal zero trust efforts are stalling because agencies cannot continuously govern privileged identities, legacy systems resist modern controls, and NHIs are multiplying faster than inventories and rotation processes can keep up, according to Delinea. The operational gap, not the policy gap, now determines whether zero trust becomes real.

NHIMG editorial — based on content published by Delinea: Federal zero trust: Turn stalled strategy into execution

By the numbers:

• The rapid growth of NHIs compounds this problem, as service accounts, application credentials, machine-to-machine tokens, scheduled task credentials, and database connection strings outnumber human identities by at least 10 to 1 in most environments.
• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

Questions worth separating out

Q: How should security teams implement zero trust for non-human identities in federal environments?

A: Start with an inventory of all privileged NHIs, then assign owners, remove standing access where possible, and enforce short-lived credentials with automated rotation.

Q: Why do non-human identities complicate zero trust architectures?

A: NHIs complicate zero trust because they multiply faster than human identities, are often overprivileged, and are frequently ignored in access reviews.

Q: What breaks when privileged access is not continuously governed?

A: When privileged access is not continuously governed, standing privilege persists, dormant accounts remain usable, and the attack surface expands across human and machine identities.

Practitioner guidance

• Inventory every privileged identity Build a current register of human and non-human privileged accounts, including service accounts, scheduled tasks, tokens, and local admin paths.
• Wrap legacy systems with compensating controls Map systems that cannot support modern authentication or policy enforcement, then apply compensating controls such as tighter segmentation, narrower privileges, and monitored jump paths.
• Automate rotation and revocation for machine credentials Move NHIs onto explicit lifecycle processes for issuance, rotation, and offboarding.

The next funding cycle should favor inventory, ownership, and rotation capabilities before additional policy orchestration?

👉 Read Delinea's analysis of why federal zero trust is stalling on execution →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Operational technology environments keep privileged access in place longer than enterprise IT usually would, because availability, vendor support, and maintenance windows limit how fast controls can change, according to Delinea. The governance problem is not just access volume but accumulated exception paths, making blast-radius control the practical priority for OT teams.

NHIMG editorial — based on content published by Delinea: Securing privileged access in OT without disrupting operations

Questions worth separating out

Q: How should security teams reduce privileged access risk in OT without causing downtime?

A: Start with the access paths that create the largest blast radius, not the ones that are easiest to change.

Q: When does privileged access in OT become a governance problem rather than an operations issue?

A: It becomes a governance problem when access persists by habit instead of by documented need.

Q: What is the difference between session monitoring and least privilege in OT?

A: Session monitoring shows what an authenticated user did after access was granted, while least privilege limits what that user can do in the first place.

Practitioner guidance

• Map every privileged access path Inventory shared administrator accounts, service accounts, remote vendor tools, jump hosts, and engineering workstation elevation paths.
• Move static credentials into controlled rotation Place privileged credentials under centralized vaulting and enforce rotation schedules that fit plant operations.
• Broker and record remote sessions Require controlled access paths for third-party and internal remote support, with proxied sessions, activity logging, and recording enabled by default.

Teams that can measure account ownership, session evidence, and task-scoped elevation will be able to reduce risk without forcing unsafe standardisation?

👉 Read Delinea's analysis of privileged access control in OT →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Manual user access reviews can consume hundreds of hours per cycle and still leave access creep, terminated accounts, and machine identities unchallenged, according to Delinea's analysis. Automation turns access certification from a spreadsheet exercise into a control that can keep pace with hybrid environments and NHI sprawl.

NHIMG editorial — based on content published by Delinea: Save time and reduce risk by automating User Access Reviews

By the numbers:

• Across customer interviews, Fastpath reduced time spent on access reviews by up to 80%, with some customers reporting savings of 120 hours per quarter.
• Norwegian Cruise Line Holdings had 450 unique reviewers, 14,000 users, and approximately 300,000 lines of access across its in-scope SOX applications.

Questions worth separating out

Q: How should organisations automate user access reviews without weakening control quality?

A: Organisations should automate data collection, reviewer routing, reminders, remediation, and evidence capture, but keep human decision-making at the approval stage.

Q: When do user access reviews become too risky to run manually?

A: Manual reviews become too risky when the organisation has multiple systems, frequent role changes, or large volumes of human and non-human access.

Q: What is the difference between access certification and provisioning?

A: Access certification checks whether existing access should remain in place, while provisioning grants or removes access in the source system.

Practitioner guidance

• Map UAR scope to business risk Classify applications by data sensitivity, fraud exposure, and regulatory impact, then set review cadence accordingly.
• Automate ownership and reviewer routing Use attributes such as department, manager, location, and role ownership to route certifications to the right decision-maker.
• Validate removals in the source system Do not count a campaign as complete until rejected access is removed in the source application and the change is verified.

With 57% of organisations lacking a complete inventory of their machine identities, certification programs that do not account for non-human access will miss part of the risk surface entirely?

👉 Read Delinea's analysis of automating user access reviews for least privilege →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Delinea’s DynamicsCon and DynamicsMinds resource roundup centers on access governance for Microsoft Dynamics 365, with emphasis on Segregation of Duties, license compliance, telemetry, and business-application risk management as identity controls strain under AI adoption and broader operational complexity. The underlying issue is not feature breadth but whether governance teams can still see, prove, and enforce access decisions fast enough.

NHIMG editorial — here’s why we think this discussion matters

By the numbers:

• Delinea's 2026 Identity Security Report confirms that AI adoption is rapidly outpacing identity controls.
• For over 20 years, organizations have relied on Fastpath, now part of Delinea, for strong internal controls, such as Segregation of Duties (SoD), in Microsoft Dynamics and across other critical business applications to reduce risk and maintain compliance.
• Fastpath solutions integrate with Dynamics 365 Finance & Supply Chain, Business Central, Customer Engagement, and with Dynamics AX and Dynamics GP.

Questions worth separating out

Q: How should teams govern access in Dynamics 365 environments?

A: Start with business transactions, not directory roles.

Q: Why do enterprise applications complicate IAM more than standard user directories?

A: Enterprise applications embed process logic, approvals, and data paths that directory IAM does not understand.

Q: What is the difference between access review and access governance?

A: Access review checks whether a permission still looks appropriate.

Practitioner guidance

• Map SoD conflicts to business transactions Identify the specific Dynamics 365 actions that should never be held by the same identity, then test roles and exceptions against those combinations before production approval.
• Use telemetry to remove dormant access Tie access review to observed use, then revoke entitlements and licenses that show no legitimate activity over a defined review window.
• Separate human and non-human access paths Document service accounts, integrations, and delegated admins as distinct control classes so they are reviewed differently from end users.

Dynamics environments expose how quickly access risk moves from human role management into service accounts, workflow automation, and delegated administration, which means control owners need one policy model for both people and NHIs?

👉 Read Delinea’s Dynamics 365 access governance resources and report →

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Application access governance teams often stall because they try to automate too broadly before establishing foundational controls, according to Delinea’s webinar preview on Fastpath implementation, SoD, critical access monitoring, and user access reviews. The practical lesson is that phased control selection and targeted automation reduce audit risk faster than trying to modernise everything at once.

NHIMG editorial — here’s why we think this discussion matters

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

Questions worth separating out

Q: How should organisations prioritise GRC controls when starting application access governance?

A: Start with the controls that reduce risk fastest and are easiest to operationalise, usually SoD, critical access monitoring, and user access reviews.

Q: When does access review automation create more risk than it reduces?

A: Automation becomes risky when it speeds up the workflow without improving the underlying decision quality.

Q: What is the difference between Segregation of Duties and critical access monitoring?

A: Segregation of Duties prevents conflicting actions from being combined in one identity or workflow, while critical access monitoring watches high-risk entitlements and events for inappropriate use.

Practitioner guidance

• Prioritise foundational control domains first Start with SoD, critical access monitoring, and user access reviews before expanding into broader automation.
• Map review ownership to a named control owner Assign explicit accountability for each review queue, exception path, and remediation step so the process does not stall after findings are identified.
• Automate evidence collection before expanding scope Use automation to pre-populate entitlements, approval history, and access context so reviewers can make decisions faster with fewer manual lookups.

That same delay now defines many NHI initiatives, where inventories, ownership, and remediation cycles can fall out of sync before control owners act?

👉 Register for Delinea's webinar on GRC maturity and application access governance →

Explore further

View Full Forum →  |  NHI Foundation Course →