A role name is a label somebody typed, while an authorisation is what SAP checks at runtime, and the RedRays Security Platform computes segregation of duties conflicts from the second because the first cannot be relied on to describe the first.
Most access reviews are run over names. A manager is sent a list of role names against a list of people and asked whether each person should have each role. That process is cheap, it is auditable, and it misses whole classes of conflict by construction.
Four reasons, each of which produces a conflict a name-based review cannot see.
| What happens | Why the name review misses it |
|---|---|
| A role grants transactions outside what its name describes. A role named for customer master data also carries vendor change, because somebody added it years ago. | The reviewer approves a role for the job the name describes. Nobody reads the authorisation contents. |
| One role carries both sides of a conflict on its own. | There is no combination of two approvals to review. A manager asked "should this person have this role?" has no way to know what is inside it, and withdrawing any other role leaves the conflict standing. |
| Access arrives through a reference user. | There is no assignment row against the person, so the person appears to hold nothing. |
| An unrestricted profile is assigned straight to an account with no role in between. | Role-based certification returns clean. The account can perform both halves of every rule in the set. |
A fifth case is quieter and just as common: standard delivered roles. A single delivered role can satisfy both sides of more than one conflict pair, so the conflict is not something the customer built and not something a review of custom roles will find.
It resolves what each account can do, field by field, and then tests that against duties written in the same terms. The output names the person, the rule, the paths and the values that matched, so the claim can be checked rather than believed. Because both sides of a rule are named as duties and not as roles, renaming or rebuilding a role does not change whether the rule fires.
| Role-name review | Authorisation-based analysis | |
|---|---|---|
| Sees a role whose contents drifted from its name | No | Yes |
| Sees a conflict carried inside one role | No | Yes |
| Sees access held through a reference user | No | Yes |
| Sees an unrestricted profile assigned directly | No | Yes |
| Distinguishes create from display | Only if the name says so | Yes, when the duty is written over the activity field and not only a transaction |
| Knows whether the person needs the access | Yes, that is what the manager brings | No |
| Knows whether a manual control compensates | Yes | Only if the control is registered against the finding |
| Produces a signed record of who approved what | Yes | Yes, when the review is run over the scan |
Judgement. An authorisation-based analysis says an account can do two things; it does not say whether that person should, whether their job requires it, or whether a four-eyes control outside SAP already catches the case. That is what the manager in a review brings, and it is why the two are run together rather than one instead of the other: the scan decides what goes on the list, the reviewer decides what happens to each line. See SAP user access reviews and mitigating controls for SoD risk.
It also has its own failure mode. A rule side that lists several transactions and accepts any one of them can be satisfied by the display transaction in the list, and the sentence attached to the finding then claims more than the person can do. That is a property of rule content, which is why rule conditions are visible in full and why a new rule is measured against a real population before it is switched on.
No. It is the only part of the process that carries business context, and it produces the sign-off an auditor asks for. What it cannot do is decide which lines belong on the list.
Role design is an intention; assignments and their contents are the fact. Conflicts arrive from composite membership, derived roles, emergency grants that were never withdrawn, delivered roles, and roles whose contents changed after the design review.
It does not care. Rules are written over authorisations, so a renamed role shows up as a different path behind the same finding.