A developer role is typically for people who manage integration and environment configuration, while a support role is narrower and focused on operational changes such as creating, deleting, or modifying connection and directory resources. The distinction matters because it limits exposure of sensitive setup controls while still letting support teams do their work. Clear role boundaries reduce privilege creep and improve governance.
How developer and support roles differ in an identity dashboard
The difference is usually one of scope, not just title. A developer role is meant to support integration work and environment setup, while a support role is narrower and aimed at day-to-day operational changes. In practice, that means the developer role can touch broader configuration surfaces, whereas the support role should be limited to the specific resources needed to keep connections and directories running.
What each role should be able to change
The useful way to think about the split is by control surface. Developer access commonly covers integration settings, testing, and environment-specific configuration that affects how the identity system connects to other services. Support access is usually constrained to operational edits on existing resources, such as creating, deleting, or modifying connection and directory objects. That separation reduces the chance that routine support work accidentally alters architecture or security posture.
Because these roles often sit close to provisioning and directory controls, the boundary should be drawn around the minimum set of actions each team needs. The developer role can be broader when it is used to build or maintain integrations, but it should still avoid unnecessary administrative power. The support role should be treated as a targeted operational function, not as a generic admin substitute.
Why role boundaries matter for governance and exposure
Clear role boundaries help prevent privilege creep. If support users gradually inherit developer capabilities, they can end up with access to setup controls they do not need, which increases the blast radius of a mistake or misuse. This is especially important in identity platforms because small configuration changes can affect authentication flows, directory sync, and downstream applications.
From a governance perspective, the distinction also improves review quality. When access is well defined, reviewers can tell whether a user still needs integration-level permissions or only operational support rights. That makes access certification more meaningful and makes it easier to detect when a role has expanded beyond its intended purpose.
Risk and Threat Considerations
Role confusion in an identity dashboard creates a common failure mode: broad developer privileges are used for routine support work, or support permissions quietly expand until they resemble full administration. That can expose sensitive setup controls, weaken segregation of duties, and make accidental misconfiguration more likely.
Failure mechanism: Overlapping role definitions let users reach higher-risk configuration paths than their job requires, which can lead to unauthorized environment changes, directory disruption, or easier abuse if an account is compromised.
Impact: The practical impact is increased blast radius, harder access review, and a higher chance that identity infrastructure changes affect production access, integrations, or downstream systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Role separation here is a least-privilege decision for identity dashboard access. |
| AC-5 — Separation of Duties | Developer and support duties should not collapse into the same access path. | |
| IA-5 — Authenticator Management | Identity dashboard roles often depend on controlled credential and token use for admin access. | |
| Recommendation — Limit each role to the minimum actions needed for its job. Split configuration authority from routine operational maintenance. Manage privileged credentials and tokens tightly for both roles. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The question is about restricting identity dashboard permissions by role. |
| GV.RM-01 — Risk Management Strategy | Clear role boundaries reduce governance and privilege-creep risk. | |
| Recommendation — Constrain access so each role can perform only its authorized tasks. Define and review role boundaries as part of access risk management. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The role split is an access-control design choice for an identity system. |
| A.5.3 — Segregation of duties | Developer and support responsibilities should be kept distinct. | |
| Recommendation — Document role-based access rules and enforce them consistently. Separate configuration duties from operational support duties. | ||
Practitioner Guidance
What to verify: Check the exact actions each role can perform, not just the role name. A support role should be able to complete operational maintenance without reaching environment-wide configuration or integration settings.
Decision rule: If a permission changes how the identity platform is built, connected, or configured, keep it in the developer role; if it only maintains existing connection or directory resources, it belongs in support.
What good looks like: Role descriptions, admin screens, and access reviews should all reflect the same boundary so reviewers can quickly tell whether a permission is operational or architectural.
Practitioner takeaway: The safest model is not “developer versus support” as labels, but a documented separation between configuration authority and operational maintenance, with no hidden overlap.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
