The network boundary has been declared dead so often that the phrase has stopped meaning anything. What is actually true now is narrower and more useful: for a company whose systems are all somebody else's software, the only control that consistently determines who can reach what is the identity layer. Everything else is a preference expressed inside a service you do not run. That has a consequence most security programmes have not absorbed. If identity is the perimeter, then identity failures are not access-management hygiene issues. They are perimeter breaches, and they should be resourced like them.
You cannot firewall software you do not host. What is left is the question of who is allowed to sign in, from what, and what happens to that permission afterwards
Here is what that actually requires, and what most organisations are missing.
The four failure points
Authentication strength, which is largely solved in principle and unevenly applied in practice — there is nearly always a legacy protocol, a service account or a break-glass path that bypasses the strong factor. Session integrity, which is where the current generation of attacks actually lands. Stealing a valid session token defeats a strong authentication entirely, and most organisations have no mechanism to detect a session being used from a context it was not issued in. Authorisation drift, the slow accumulation of permissions granted for a project, a cover arrangement, an urgent request. Nobody revokes them, and after four years the average long-serving employee can reach a startling amount. Lifecycle at the edges, meaning contractors, partners, integrations and anyone whose departure is not processed by a human resources system. This is where dormant access lives.
| Review area | Control to assess |
|---|---|
| Authentication | Strong factors and documented exception paths |
| Sessions | Context signals and appropriate re-authentication |
| Authorisation | Time-bounded grants and renewal ownership |
| Lifecycle | Departures of suppliers, partners and non-human identities |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What to actually do
Put the strong factor on everything, then go looking for the paths that avoid it — the exception list is the real attack surface and it is always longer than the register suggests. Treat session context as a signal: device, location, behaviour. A session token used from a new context should require re-authentication, and this is the single highest-value control available against the dominant attack pattern. Make authorisation time-bounded by default. Permissions that expire unless renewed solve drift structurally, where review cycles solve it once and then decay. And extend joiner-mover-leaver to every identity, including the ones that are not people and the ones that belong to other companies.
The part that is genuinely hard
Recovery. If identity is the perimeter, compromise of the identity provider is compromise of everything, and very few organisations have a tested plan for operating while their directory is untrusted. That plan is unglamorous, nobody funds it, and it is the difference between a bad week and an existential one.
Practical Guidance for Identity Strategy Assessment
- Enumerate every authentication bypass and close or justify each.
- Add session context signals and force re-authentication on change.
- Make permissions expire rather than relying on review.
- Cover non-human and partner identities in the lifecycle.
- Separate administrative identities from daily ones.
- Test identity provider compromise as a scenario, with a written plan.
- Monitor authentication events as security telemetry, not audit logs.
- Keep a break-glass path that is offline, tested and watched.
The Regional Angle
The first regional consideration is that identity in Gulf organisations frequently extends well beyond the employee population in ways the directory does not model. Contracting and subcontracting arrangements, manpower supply firms and outsourced operational teams mean a large number of people with legitimate system access are employed by somebody else entirely, and their departure generates no signal in your human resources system. The practical control is a contractual obligation on the supplier to notify departures within a fixed period, backed by expiry-based access rather than trust in the notification. The second concerns shared and role-based accounts, which remain more common here than in comparable Western organisations and are usually defended on operational grounds — a shift-based counter, a site office, a team mailbox. Every shared account destroys attribution at exactly the point where you need it most, and in a region with high staff rotation the population of people who once knew the password grows continuously and invisibly. Replacing them is unpopular and it is the highest-return identity work available in most regional environments. The third is about administrative access held by external parties. Where systems are implemented and supported by regional integrators, privileged credentials often sit with staff in a third country, outside your jurisdiction and your employment framework, sometimes shared within a support team. Regulators here have become noticeably more interested in that arrangement, and the reasonable position is named individual accounts for supplier staff, time-bounded, with activity logged on your side rather than theirs.
The objection worth taking seriously
The strongest objection is that declaring identity the whole perimeter concentrates risk in a single provider and then tells you to trust it more. If every application federates to one directory, then that directory is a single point of catastrophic failure, subject to outages you cannot fix, vulnerabilities you cannot patch and vendor decisions you do not control — and the industry has seen enough identity provider incidents to know this is not theoretical. Defence in depth argues for keeping independent controls, not for collapsing everything onto one dependency. That is correct, and it is the main structural weakness of the model. The response is that the concentration already happened; the only open question is whether you manage it deliberately. Federating to one provider concentrates risk visibly, while the alternative — dozens of applications with local credentials — distributes it into places nobody monitors and nobody offboards, which is worse in every observed incident. What the objection correctly demands is the part organisations skip: a tested plan for operating when the identity provider itself is compromised or unavailable, independent logging of authentication events so you are not relying on the compromised system to tell you what happened, and a break-glass path that does not depend on the provider being healthy. Concentrate the perimeter, then treat it like one.
Common Questions
Is strong authentication enough?
No. It addresses credential theft and does nothing about session theft, which is where the current attack volume sits.
How do we handle service accounts?
As identities with owners, scopes and expiry dates. The ones that cannot use a strong factor need compensating controls and a named person responsible for them.
What about legacy applications that cannot federate?
Put them behind an access proxy or accept that they are outside the perimeter and treat them accordingly. There is no third option that is honest.
What should we expect over the next twelve months?
Expect session-theft techniques to keep outpacing authentication improvements. Expect non-human identities to outnumber human ones in most environments. Expect regional supervisors to ask about supplier privileged access specifically. And expect at least one significant incident to turn on an identity provider dependency nobody had mapped.
Identity Strategy Assessment — we find the authentication bypasses and the dormant access first, because that is where the perimeter actually leaks.