They become necessary when native security alone cannot separate duties cleanly or when the cost and complexity of perfect separation outweigh the business benefit. In those cases, teams should use controls that add review, approval, and traceability around sensitive actions. Shared passwords and field protection can help, but they require disciplined password management and additional audit testing.
When Workflow Approvals Become the Right SoD Control
In Dynamics GP, workflow approvals become necessary when native role design cannot separate duties cleanly without breaking the business process. That usually means the same person can initiate, prepare, and finalise a transaction unless another control intervenes. Approvals do not replace segregation of duties, but they can add a review gate, preserve traceability, and reduce the chance that one user can complete a sensitive transaction end to end.
The practical question is not whether approvals are “better” than access control, but whether they are the least-bad control for a specific process. If the transaction volume is low, the monetary or compliance impact is material, and clean role separation would be too expensive or operationally awkward, an approval workflow is often the control that keeps the process workable without leaving it fully unchecked.
Approvals are strongest when they are tied to a clear exception path, a defined approver, and evidence that the review actually occurred. They are weaker when they are informal, override-heavy, or used to mask a role design that should have been fixed in the first place. For broader access-governance context, IAM and IGA Basics explains how approval gates fit into identity and entitlement control.
Why Shared Passwords and Field Controls Sometimes Fill the Gap
Shared passwords and field-level controls tend to appear when Dynamics GP cannot enforce the exact separation the business wants through standard permissions alone. Shared passwords are a workaround, not a clean design pattern. They may be used to restrict access to a sensitive action while keeping the user experience manageable, but they also collapse accountability unless the surrounding process compensates with logging, reconciliation, and tight ownership.
Field controls serve a different purpose: they limit what a user can see or change inside a screen or transaction. That matters when SoD risk is not only about who opens the record, but also about who can alter a critical field, such as an amount, approval status, vendor detail, or account coding. If the field itself creates the conflict, then protecting the field can be more effective than trying to redesign the entire role structure.
These controls work best when the underlying business rule is simple and stable. They become fragile when teams use them to paper over too many exceptions, because complexity shifts from security design into procedural memory. For the password side of that trade-off, Password Security and Password Manager Guide is the relevant reference point for managing shared credentials without creating avoidable reuse and rotation problems.
What Makes SoD Compensating Controls Acceptable in Practice
Compensating controls are acceptable when they are proportionate to the risk, documented, and tested. In practice, that means the organisation should be able to explain why native SoD is not achievable, what control now carries the risk, and how the team knows the control is operating. If no one can show that evidence, the control is only a convenience, not a compensating measure.
The strongest compensating pattern is usually a combination of approval, restricted access, and post-transaction review. Each layer covers a different failure mode: approval checks the request, field protection limits the action, and review catches misuse or bypass. That layered design is preferable to relying on a single shared secret or an undocumented manual step.
For a direct SoD control lens, Segregation of Duties (SoD) Guide covers how to build rulesets, detect conflicts, and manage mitigations, including the cases where preventive separation is not fully achievable.
Risk and Threat Considerations
Once approvals or shared passwords become part of SoD, the main risk is that accountability becomes weaker even if the process still “works.” A shared credential can hide who performed the action, and a poorly designed approval chain can turn into rubber-stamping, where the control exists on paper but does not materially reduce privilege abuse or fraud.
Failure mechanism: The control fails when the organisation treats procedural review as equivalent to true separation, or when shared access, weak logging, and excessive exception handling make it impossible to attribute the sensitive action to a specific person.
Impact: Misstated transactions, unauthorised changes, control-audit findings, and higher exposure to fraud or concealment of errors can result, especially where the same business user can both prepare and effectively approve the work.
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 CIS Controls v8 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 | SoD gaps are often closed by restricting who can perform sensitive GP actions. |
| AU-2 — Event Logging | Approvals and shared passwords need traceability to preserve accountability. | |
| Recommendation — Apply AC-6 to limit sensitive actions to the smallest feasible set of authorised users. Log approval and transaction events so compensating controls remain auditable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD workarounds depend on controlled access rights and restricted functions. |
| Recommendation — Define and enforce access rules that separate incompatible duties where possible. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared passwords and SoD exceptions depend on disciplined account handling. |
| Recommendation — Review account usage and remove shared access paths that weaken accountability. | ||
Practitioner Guidance
What to prioritise: Start with the transaction that creates the highest SoD risk, not the one that is easiest to fix. If the same user can create, modify, and finalise the same business event, that process deserves the first compensating control review.
What to verify: Confirm that every approval leaves an auditable trail, that shared passwords are tightly limited in scope, and that field controls block the exact conflict rather than merely slowing users down. If you cannot prove who did what, the control is too weak to rely on.
Common mistake: Teams often accept shared passwords as a permanent design choice without assigning ownership, rotation discipline, and periodic test evidence. That shortcut usually shifts SoD risk from the application layer into the operating model.
Practitioner takeaway: Use compensating controls only when they materially reduce the specific conflict, and treat them as evidence-bearing controls that require review, attribution, and periodic challenge, not as a substitute for fixing role design where separation is actually possible.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
