Give them controlled extensibility through templates, not unlimited freedom. Let tenants clone or override approved base roles within explicit limits, then keep the backend authoritative so the customisation layer cannot bypass tenant isolation or create unreviewed privilege paths.
Why This Matters for Security Teams
Enterprise customers asking for custom role are usually asking for fit, not for a new trust model. The security risk appears when product teams let tenants define arbitrary permissions, because that turns role management into a hidden policy engine and makes privilege review far harder. NHI Management Group notes that 97% of NHIs carry excessive privileges, which is exactly the kind of drift custom roles can amplify if the backend stops being authoritative.
The safer pattern is controlled extensibility: approved base roles, explicit inheritance rules, and hard limits on what tenants can change. That keeps tenant-specific business language on the surface while preserving centralized control over the real access graph. This also aligns with the direction of the NIST Cybersecurity Framework 2.0, which emphasizes governed, auditable access decisions rather than ad hoc exceptions. The practical question is not whether custom roles exist, but whether they can alter effective privilege without review. In practice, many security teams discover that custom-role sprawl becomes a breach enabler only after access reviews fail to explain who can do what.
How It Works in Practice
Teams should treat custom roles as constrained configuration, not tenant-owned policy authoring. Start with a small catalog of base roles that map to stable job functions or workload patterns, then allow customers to clone a role and modify only permitted dimensions such as feature scope, resource scope, or approval workflow. The backend must translate those selections into authoritative permissions, with tenant isolation enforced server-side and never delegated to the UI or to client-side logic.
In practice, the safest design includes three layers:
- Base roles that are security-reviewed and versioned.
- Tenant-specific overlays that can only narrow or label access, not invent new privileges.
- Policy checks at request time so the effective permission set is evaluated centrally before any action is executed.
That architecture is consistent with the governance emphasis in the Ultimate Guide to NHIs — Why NHI Security Matters Now, especially where excessive privilege and poor visibility create compounding risk. It also fits the broader access-governance posture in NIST Cybersecurity Framework 2.0. For higher-risk environments, current guidance suggests pairing custom roles with immutable audit logs, periodic diffing against the approved base template, and explicit review before any new permission is exposed to customers. These controls tend to break down when role definitions are embedded directly in application code because product releases then become the only practical way to revoke or tighten access.
Common Variations and Edge Cases
Tighter role controls often increase support overhead, so organisations need to balance customer flexibility against review burden and incident exposure. That tradeoff is especially visible in multi-tenant SaaS, regulated environments, and platforms that expose both human and machine access through the same entitlement model.
Where customers demand more freedom, best practice is evolving rather than settled. Some vendors allow scoped custom permissions only within a fixed taxonomy; others support composable roles but prohibit direct privilege assignment. The key boundary is that customers may express business intent, but they should not be able to bypass tenant isolation, grant cross-tenant access, or create unreviewed admin-like paths. If the product supports non-human identities such as service accounts or API clients, the same model should apply to those workloads, with separate templates for runtime access and stronger limits on secret-bearing roles. For situations where custom roles must be approved by policy, publish the allowed pattern up front and keep exceptions rare and time-bound. The model becomes fragile when customers expect completely arbitrary roles, because the review process cannot scale to every bespoke permission combination.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Custom roles can create excessive NHI privileges and weak rotation boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Custom role design must still enforce least privilege and controlled access. |
| NIST AI RMF | Custom roles for agentic or AI-driven workloads need governed, auditable decision paths. |
Keep tenant-defined roles bounded to approved templates and review effective privileges regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
