How should teams handle static roles in ERP and SaaS when Zero Trust is the target?

Why static ERP and SaaS roles are only a starting point under Zero Trust

Static roles still matter because they encode job function, segregation of duties, and the default access an account should start with. The problem is that a role alone rarely captures the sensitivity of the transaction, the device, location, data class, or session state. Under zero trust, the role becomes one input to policy, not the final decision.

That distinction is important in ERP and SaaS because many of the highest-impact actions, such as payments, vendor changes, journal approvals, data exports, or admin changes, should not be governed by a fixed entitlement alone. A policy layer can apply zero trust identity principles so the same user can be allowed in one context and challenged or blocked in another.

In practice, static roles are best treated as coarse grouping. Attribute and context signals, such as business unit, environment, device trust, time window, risk score, and approval path, let teams make the authorization decision match the action instead of forcing every exception into a new role or a broader entitlement.

How centrally governed policy changes the authorization model

Moving from role-first authorization to policy-first authorization changes where logic lives and how quickly it can adapt. Instead of rebuilding application entitlements every time the business changes, teams define a centrally governed decision model and let applications consume it. That is the practical bridge from RBAC to a more expressive model such as ABAC or policy-as-code.

This is especially useful when one role spans multiple systems with different risk levels. A finance analyst may need routine read access in ERP, but the same identity should face a stronger policy for payment release, master-data edits, or sensitive exports. IAM and IGA basics is a useful reference for the underlying shift from static entitlements toward governed authorization and access review.

Central governance also improves consistency. If policy is defined once and enforced across ERP and SaaS applications, security teams can align decision logic with business controls, reduce role explosion, and keep entitlement reviews focused on the few static permissions that still need to exist.

What good implementation looks like in ERP and SaaS

The strongest pattern is to keep roles as coarse entitlements and push sensitive decisions to policy enforcement points that evaluate role, attributes, and context together. That means ERP and SaaS administrators should identify which actions remain purely role-based, which require step-up checks, and which should be denied unless a just-in-time exception or approval is present.

For cloud-delivered systems, it helps to map access to a small set of control questions: who is requesting, what action is being attempted, what data or object is involved, and whether the context matches the approved use case. Where teams need a Zero Trust reference point, NIST SP 800-207 Zero Trust Architecture provides the policy-and-verification model that supports this approach.

Where the system contains service accounts, integrations, or workload-to-workload access, the same principle applies: static credentials or broad app roles should not become invisible standing privilege. Guide to SPIFFE and SPIRE is relevant where teams want short-lived, workload-centric identity signals instead of brittle shared secrets or long-lived static trust.

Practitioner Guidance

What to prioritise: Start with the sensitive ERP and SaaS actions that create the most business impact, not with low-risk read-only access. If an action can move money, change master data, alter approvals, or export regulated data, it should be policy-evaluated rather than role-granted by default.

What to verify: Confirm that your policy engine can use authoritative identity data, device or session context, and transaction attributes from the same source of truth. If teams cannot explain why a specific user was allowed at a specific moment, the model is still too static.

Common mistake: Teams often keep adding roles to avoid building policy logic. That usually creates role explosion, slower reviews, and a false sense of Zero Trust because the authorization model still behaves as a hard-coded entitlement map.

Practitioner takeaway: Zero Trust does not mean eliminating roles; it means preventing roles from being the only thing that decides access when the action is sensitive.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should teams handle secrets that have no obvious owner?
• How should security teams implement Zero Trust SaaS in practice?
• How should security teams apply zero trust to SaaS environments?