Document Portal Entitlement & Access Control (2026)

Most document portals answer one question: is this person logged in? That is enough for a resource library and nowhere near enough for technical documentation.

In aviation, defence, industrial equipment and regulated publishing, the question is narrower and much harder: which documents is this specific customer entitled to see, at which revision, for the configuration they actually own? Getting that wrong is not a bad user experience. It is disclosing one customer’s material to another, or handing an engineer a document that does not apply to their equipment.

Access is not one problem, it is four

Teams building these portals usually discover the distinctions in the wrong order, so it is worth naming them up front.

Authentication — who are you? Solved, and rarely where the difficulty is.

Authorisation by role — what kind of user are you? An administrator, a partner and a customer see different things. This is where most portals stop.

Entitlement — what have you specifically bought or been granted? Two customers with identical roles see different document sets, because entitlement follows the commercial relationship rather than the job title.

Configuration — which variant applies to you? Two customers may both be entitled to the same manual and need different revisions of it, because their equipment differs.

A system that models the first two and treats the second two as filtering will eventually leak. The last two are data problems, not interface problems.

Entitlement follows the purchase, not the person

This is the shift that makes these portals different from ordinary intranets.

For the SES content portal, the core capability is purchase-driven entitlement — secure access driven by what a customer has bought, with role-based views separating technical content from marketing material and configuration-specific assets. The portal exists precisely because the previous systems could not support secure, configuration-specific access.

Two consequences follow, and both surprise people.

The entitlement rules are business rules, not settings. They have to be defined with the commercial side of the business, in discovery, before anything is designed. They encode how the company actually sells.

Entitlement changes without anyone touching the portal. A purchase, a renewal, a lapsed contract — all change what someone should see. If entitlement is a list an administrator maintains by hand, it will be wrong within a quarter.

Enforce it at the data layer

The single most important architectural decision in one of these systems.

It is tempting to filter in the interface: run the query, then hide what the user should not see. This is convenient, and it fails as soon as anything else queries the data — an API, an export, a search index, a report, or a bug in one endpoint out of forty.

The rule that holds up is that a query should be incapable of returning something the requester is not entitled to. Scoping belongs as close to the data as possible, so every consumer inherits it rather than each one re-implementing it. Get this wrong and you are one forgotten endpoint away from a disclosure.

It also matters more as AI enters the picture. A retrieval system pointed at a document store will happily surface whatever the store returns. If entitlement is enforced in the UI, the model never sees the rule.

Revision is part of access

In technical publishing, “which document” and “which version of it” are the same question.

A reader needs the revision that applies to their configuration, and often needs to prove which revision applied on a given date. So versioning cannot be a convenience feature bolted on later — the document model has to carry revision, configuration and state from the beginning, and the entitlement rules have to operate on that model rather than on filenames.

This is also the difference between a portal and a file share with logins. A file share gives you the latest thing someone uploaded. A publications portal gives a specific customer the correct revision for their equipment.

What discovery has to produce

For a portal like this, discovery is not a design exercise. Before anything is built you need:

The entitlement model — what grants access, at what granularity, and what revokes it
The role definitions — internal and external, and what each may see and do
The configuration model — how a customer’s specific setup maps to document variants
The integration picture — where entitlement data comes from, and what happens when the upstream system is unavailable
The hosting and security constraints — because these frequently determine the architecture rather than following from it

For SES that meant wireframes and mid-fidelity designs alongside a technical analysis report covering cloud infrastructure, entitlement logic and integration needs. The report is the part that decides whether the build succeeds.

The failure modes

Entitlement as a manual list. Works at launch, wrong within months, and nobody notices until a customer sees something they should not.

Filtering in the interface. Every new consumer of the data is a new chance to forget.

Treating revision as metadata. If the model cannot express which revision applied when, you cannot answer the question that regulated industries ask.

Designing the UI first. The interface for a portal like this is comparatively simple. The rules underneath are not, and they should be settled before pixels.

When you need this

If your documents are the same for everyone, you do not need entitlement — you need a well-organised library and good search.

You need this when access follows the commercial relationship, when configuration determines which variant applies, or when you have to prove after the fact who could see what. That is common in aviation, defence, industrial equipment and regulated publishing, and rare almost everywhere else.

If that describes your situation, we are happy to talk it through.

Entitlement and Access Control in Document Portals