Tiered access, dual use capability, and who is allowed to do what

The written material

Why access became tiered

For most of the history of software, access to a capable tool was binary. You had the licence or you did not. Capability that is both genuinely useful for defence and genuinely useful for attack has pushed providers towards something more graduated, and the shape it has settled into is consistent enough to be taught as a pattern.

There are typically three levels. A broad tier available to any customer, covering the large majority of legitimate work. A verified tier, which an organisation applies for, and which relaxes restrictions on a category of work that is legitimate but indistinguishable from misuse without knowing who is asking. And a restricted tier, negotiated commercially with a small number of partners, for the most sensitive capability of all.

The names differ by provider and will keep changing. The structure is what to learn, because an organisation that understands why the middle tier exists can evaluate any provider's version of it in an afternoon.

Dual use, and why the middle tier has to exist

Dual use capability is capability whose defensive and offensive applications are the same capability. This is not a grey area at the edge of the subject. It is most of security work.

Understanding how an attack technique operates in enough detail to detect it is the same understanding required to perform it. Building a tool that simulates an adversary in order to test defences produces a tool that can attack. Analysing why a vulnerability is exploitable, so that the fix can be prioritised correctly, is analysing how to exploit it.

A provider looking at a request in isolation cannot tell these apart from the same request made with harmful intent, because there is nothing in the request to tell apart. The only distinguishing information is who is asking and why, and that information lives at the organisation, not in the sentence. That is exactly what a verification tier collects.

Prohibited is not the same as restricted

Two categories are routinely confused and they behave completely differently.

Prohibited use is conduct that has no legitimate version. Building tooling whose only purpose is to extort, to exfiltrate at scale, or to cause harm to people. Verification does not unlock it, no tier grants it, and an organisation that applies expecting it to has misunderstood the programme it is applying to.

Restricted dual use is conduct with a real defensive purpose that is gated until context is supplied. Exploitation analysis, adversary simulation, offensive tooling built for testing your own estate. This is the category a verified tier is for.

The distinction matters practically because it tells an organisation what applying can and cannot achieve, and because a policy that blurs the two produces staff who believe the whole subject is arbitrary.

Verification is organisational

Verification is generally granted to an organisation and bound to its credentials rather than to a person. That has consequences that are easy to miss and expensive to miss.

It means the organisation is accountable for what is done under it, including by staff who never saw the application. It means access should be tied to individual accounts within the organisation rather than a shared credential, or the accountability cannot be traced past the front door. It means offboarding matters, because a leaver with a credential still holds the organisation's verification. And it means an individual cannot take the status with them when they move.

There is usually a separate and much higher bar for organisations that want to pass such capability through to their own customers, which is a different question from using it internally and should never be assumed to follow from the first.

• Bind access to named individual accounts, never a shared key
• Keep a register of who holds access and why they need it
• Remove access at offboarding on the same day, not at the next review
• Treat the credential as a controlled asset with an owner
• Check whether onward provision to your own customers is in scope before assuming it

Access is not authorisation

This is the most important sentence in the module and the one most often skipped. Being permitted to use a capability is entirely separate from being authorised to use it against a particular target.

Verification is granted by a provider. Authorisation to test a system is granted by whoever owns that system, in writing, with a defined scope, defined dates and named contacts. In the United Kingdom, accessing a computer system without the owner's authorisation is an offence under the Computer Misuse Act 1990, and no provider tier changes that in any respect.

The failure mode is not usually deliberate. It is scope drift: a test that was authorised for one range extends to an adjacent one that turns out to belong to somebody else, or an assessment of a supplier's system where the supplier was never asked.

What a sensible internal policy actually says

A workable policy on this is short. Long ones are written to be shown rather than followed, and staff resolve the gap by not reading either.

It should name an owner. It should state what these tools may be used for and, more usefully, give two or three concrete examples of what they may not. It should state what data may be sent to them, which is where most organisations have a real and unexamined exposure. It should say access is individual and logged. And it should say who to ask when something falls outside all of it, because the alternative to a named person is a quiet decision made by whoever is under the most pressure.