The access review campaign comes round at the same time every year. A team manager receives a file: several hundred rows, one per right, identified by application codes — GESCLI_CONS_N2, REF_ADM, EXP_COMPTA_RW. They are asked to confirm, for each of their people, that the access is still justified. They have two weeks, and a business to keep running in the meantime.

They approve everything. This is not negligence: it is the only available answer. They are being asked to rule on technical objects whose exact scope, and whose actual capabilities, they do not know. Removing a right in error will block someone tomorrow morning and will be noticed within the hour. Keeping it will produce no visible consequence for years — and probably never in front of them. The audit report records a campaign closed at 100%. The mechanism that produced those hundreds of rows has not been touched.

This scene is usually read as an execution problem: wrong tool, poor ergonomics, disengaged managers. It is in fact the symptom of something missing much earlier. An entitlement model is the technical translation of a model of the organisation. When that model is written down nowhere, every application invents its own, and the only description of “who does what” the company possesses becomes the sedimented sum of its access rights — which is to say a faithful picture of the organisation as it stood ten years ago, amended by last week’s emergencies.

The ratchet

Start with the asymmetry, because it explains why the problem resists good intentions.

A departure is handled reasonably well. It is dated, visible, and carried by a process that exists: the badge comes back, the account is disabled, someone signs. An internal move has none of those properties. The person stays, the account stays, the identity does not change — and nothing in the chain of events carries the instruction to remove.

The addition, by contrast, is thoroughly equipped. It has a requester — the new manager; an urgency — the person cannot work; a channel — the ticket; and a turnaround time that is monitored. Removal has none of this: nobody asks for it, nobody derives a personal benefit from it, and it carries an asymmetric risk. Doing nothing is invisible; getting it wrong is immediate.

Every individual decision is therefore rational, and it is their sum that produces the result. Rights only accumulate in one direction.

Accumulation of access rights across one person’s successive internal moves Rights A Rights A Rights B Rights A Rights B Rights C Rights A Rights B Rights C Rights D Position APosition BPosition CPosition D none of these rights was ever removed rights of the position held rights inherited from earlier positions
Figure 1 One person, four successive positions. At each move, the rights of the new position are requested, processed and granted; the rights of the previous one are asked for by nobody and stay in place. The accumulation is not an execution failure: it is the default behaviour of a process that only has an event for granting.

The consequence is counter-intuitive, and worth stating plainly in committee: the most broadly entitled profile is neither the new joiner nor the contractor, but the long-serving employee who has held four positions. Exposure grows with tenure, versatility and loyalty — the exact opposite of what the security policy claims to organise. And because that accumulation is spread across thousands of people, it appears on no dashboard; it exists only in the complete graph, which nobody looks at.

The annual review does not fix the mechanism

The usual answer to this finding is the recertification campaign. It fails reproducibly, for three distinct reasons that are better kept apart.

It asks for a business decision about technical objects. A manager reasons in situations: “this person prepares files, they do not approve them.” The file put in front of them speaks of profiles, groups and codes. Between the two, a translation is missing — and the absence of that translation is precisely the underlying problem, not a display inconvenience.

It replays the very asymmetry it claims to correct. Approving is free and instant; refusing requires checking, taking responsibility, and possibly unblocking someone urgently three days later. Under any realistic time constraint, the campaign mechanically selects bulk approval.

It addresses the stock while the defect is in the flow. It is a detective control applied to a design defect. It can surface an isolated case; it cannot reduce an accumulation that rebuilds itself all year long, at the pace of internal moves.

None of this makes the review useless: it answers a genuine obligation and it catches anomalies nothing else catches. What is wrong is treating it as the instrument of risk reduction. That misunderstanding is what leaves the problem intact year after year, with the satisfaction of a green indicator.

Three shifts make a review considerably more useful without changing its frequency at all. First: present business roles rather than codes, even at the cost of some precision in the scope shown — a manager who understands what they are certifying decides, a manager who does not understand approves. Second: present the differences rather than the stock — what has changed since the last campaign, and what is no longer consistent with the person’s current situation. Third: put the right side by side with its actual use. A right that has not been exercised once in twelve months does not need to be certified; it needs to be removed. And if removal is reversible within minutes, that decision stops being risky.

Three different things called a “right”

Three objects live under the word “entitlement”, and their natural lifetimes have nothing in common.

The role is tied to a position. It is durable by nature, and its end is perfectly well defined: it arrives when the person leaves the position. It is the only one of the three that may legitimately settle in for the long term.

The delegation is tied to a circumstance: an absence, an interim arrangement, a temporary mandate. Its end is known at the very moment it is granted — often to the day.

The exceptional elevation is tied to an operation: an incident, a migration, a manual correction. Its end is sharper still: the closure of the operation.

The problem is not that these are confused intellectually — most teams distinguish them perfectly well in conversation. It is that all three go through the same granting mechanism, and that mechanism cannot express a duration. It knows one verb: grant. So it grants everything forever.

Actual period of use and actual lifetime for three kinds of access right granted time Role tied to a position change of position Ends with the situation that justifies it. Delegation tied to an absence absence No end date: the delegation outlives what justified it. Elevation tied to an operation incident The exceptional access becomes the everyday access.
Figure 2 The axis carries no scale: what matters is the gap between the period during which a right is useful and the period during which it exists. A role properly derived from a position ends with it. A delegation and an elevation, granted by the same gesture as a role, inherit its lifetime — which is to say none.

The costliest form of this confusion is the permanent administration account. Elevation, which ought to be a transient state justified by an operation, becomes an attribute of the person — often the same handful of people, often the ones who are indispensable everywhere, and whose account ends up opening the entire information system without any decision ever having been taken about that scope.

Where the authority lives

This brings the properly architectural question, which is neither “which tool” nor “which repository”, but: what, in the information system, is authoritative about what a person is today — their entity, their position, their perimeter — and where is that translated into rights?

Three answers coexist in most organisations, and they are not equivalent.

In each application. This is the default situation, including where a central directory exists. Every application has its own user management screen and its own notion of the business: what it calls a “case handler” does not cover what the next one calls by the same name. No event propagates, because there is nothing to propagate towards.

In a technical directory of groups. This is progress in execution, not in meaning. A group named GRP_APP7_PROFIL3 says nothing about a business situation: the storage of rights has been centralised, not the decision that underpins them. The organisation then holds an exact inventory of rights it still cannot interpret.

In an explicit model. The person’s situation — contract, entity, position, perimeter — feeds a business role, and that role is what applications consume. The missing link, almost always, is the middle one.

Two ways of connecting a person to their application rights, and what each allows Direct assignment Person App A App B App C App D granted case by case Each application defines its own notion of the holder. A change of situation triggers nothing. An explicit chain HR status Business role App A App B App C App D recomputed on events The role is defined once and consumed by all. A change of situation recomputes the rights.
Figure 3 On the left, the person is wired directly to the rights of each application: as many links as applications, each granted in isolation, and no point at which a situation can be retranslated. On the right, the situation is translated once into a business role; applications consume that role, and a change of situation becomes an event that produces an effect again.

This model has a failure mode of its own, and a common one: role explosion. In trying to cover every particular case, an organisation creates one role per person and reproduces direct assignment under more flattering vocabulary. A simple rule guards against it: a role with a single holder is not a role, it is an exception that has been given a name. The model should stay deliberately coarse — it covers the bulk of situations, and the residual gap is handled with temporary rights, not with one more role.

One distinction avoids most of that drift: separate what a person may do from what they may do it to. The role expresses the first; the branch, the portfolio, the legal entity or the country express the second. Conflating them multiplies the number of roles by the number of perimeters, and that is how a model of twenty roles becomes a catalogue of six hundred. The perimeter is data carried by the person, not an additional role.

One point is rarely examined: who is entitled to define a business role? The profiles shipped as standard with a packaged application constitute a model of an organisation — the product’s own, inherited from its other deployments. Adopting them as they come, without testing them against the segregation of duties the company actually wants, means letting a third party describe the organisation. That is a perfectly acceptable trade-off when it is made consciously; it rarely is.

What makes a right revocable

A right becomes revocable at the moment it is granted, not at the moment someone tries to remove it. The end condition therefore has to be written with the grant, in one of three forms only.

Expiry: a date, beyond which the right disappears without any decision being required. This is the natural form for delegations and elevations.

Derivation: the right is not granted but derived from a situation, and it disappears along with it. This is the natural form for roles — and the only one that makes an internal move automatically clean.

Review: failing the other two, a date at which the question will be re-examined, with a named owner.

A right that falls under none of the three is a perpetual commitment nobody approved and everybody will pay for — in exposed surface, in review workload, and in the inability to answer “who can do this?” on the day the question is asked seriously.

Two categories almost always escape this framework, and they are the most sensitive.

Non-human accounts. Integrations, robots, service accounts, connectors. They are often the most privileged things in the information system, and they have no moves, no departures and no line manager: no event in the lifecycle of people triggers their review. They are frequently shared between several uses, which makes it impossible to know what restricting them would break — and that alone is enough to prevent any reduction. The workable minimum comes down to three requirements: a named owner who is a person and not a team, a documented use, and a ban on one account being shared by two integrations. That last rule looks like nothing; it is what makes the right divisible later on.

Administration privileges. The useful distinction is not between administrators and users, but between the right to elevate and the elevated state. An elevation that is requested, justified, time-bounded and logged costs little to put in place and removes the most dangerous category in the estate: the powerful, dormant account nobody remembers.

Finally, segregation of duties — whoever enters does not approve, whoever orders does not receive — is a business requirement, not a tooling constraint. Expressed in application profiles, it is lost at the first change of package. Expressed in business roles, it outlives the applications that implement it, and it can be verified across them.

What architecture has to hold

Architecture’s job is not to administer rights. It is to bring into existence the model without which nobody can decide.

That means treating the role model as a first-class enterprise architecture artefact — derived from business capabilities and processes, maintained over time by the organisation, and not produced once by a project that then ends. It also means requiring every new application to consume that model rather than institute one more of its own: a requirement that has to be weighted in the award criteria, failing which it does not exist. And it means moving review from the calendar to the event: an internal move, the end of an assignment, the closure of an incident are the only moments at which removal is both legitimate and free. An annual campaign always arrives too late to be anything other than an observation.

The indicators follow the same logic, and none of them requires a particular tool to produce. How many rights carry an end condition, in one of the three forms? How many people still hold rights attached to a position they no longer occupy? How many technical accounts have a named owner, and how many are shared between several uses? What is the ratio between the number of defined roles and the number of actual positions — a ratio close to one signals a model that is not one? And the most honest, the one that summarises all the others: how many rights were removed this year, compared with how many were granted?

What does not fall to architecture deserves to be said just as plainly: the choice of identity management tool. A tool deployed on a non-existent model automates the accumulation; it merely makes it faster, better logged and harder to undo.

The document nobody wrote

Every organisation holds a document that describes exactly who is allowed to do what. It has no author, it was never approved, it faithfully records every emergency of the last fifteen years, and nobody has ever read it: it is the entitlement table.

For as long as it remains the only one, the organisation keeps describing itself by sedimentation, and it is the oldest and least examined decisions that prevail. Writing the model costs almost nothing while the rights have not yet been distributed — it is a design question, a few dozen roles and a rule about endings. Reconstructing it from what has already been granted is a programme, and that is the ordinary price of an architectural decision taken ten years late.