ECZ-ID for MSPs & MSSPs
For MSSPs, MDR and SOC teams
A different object from an alert, and a different object from a log.
You already run detection and response. This is the record of authority behind the machine actors you and your customers operate — who authorised them, what state applies right now, and what your customer can check without going through you.
No signup. Your answers are evaluated in your browser and are never transmitted.
Designed to work alongside your RMM, PSA, IAM, OAuth and security controls — not replace them.
The artefact
What an operator-owned log cannot settle on its own
Your logs are not the problem. Telemetry is the operational truth of a security operation — what happened, on which host, in what order, under which identity — and detection, triage, containment and post-incident work all run on it. It is necessary, it is valuable, and nothing on this page replaces it or suggests otherwise.
What an operator-owned log cannot do on its own is hand an external relying party — your customer, their insurer, their auditor, their own enterprise buyer — something they can check without depending on your tooling and your good faith. To read it they need your platform, your retention window, your export and your reading of it. Everything they conclude, they conclude through you.
That is a structural property of who owns the record, not a criticism of the record. A log written by the operator, held by the operator and read through the operator is exactly what a log is supposed to be. It is simply not the artefact that answers “who authorised this machine to act for me, and can I confirm that myself?” — because that question is asked about you, and an artefact you control cannot settle it.
| Object | What it records | Who holds it | How an outside party reads it |
|---|---|---|---|
| Alert | A condition your detection logic matched, at a moment in time. | Your detection and response tooling. | Through you — your console, your triage, your write-up. |
| Log / telemetry | What happened, in sequence, with timestamps, across hosts, identities and network. | Emitted by the system, collected and retained by you. | Through you — your platform, your retention window, your export. |
| Authority record | What the customer authorised, who is answerable for it, what state applies now, and what evidence was referenced. | You record it. The customer confirms it. | Directly — a proof view the customer opens themselves. |
The reverse is equally true, and stating it is the price of stating the first part. An authority record will never tell you that a process spawned at 02:14, that a token was used from an unfamiliar network, or that a mailbox rule was created. It is not an account of what happened. Your telemetry is the only thing that is, and this sits beside it.
Alongside, not instead of
Where it sits next to your stack
Every layer below does what it was built to do, and none of them was built to hold a per-customer record of who authorised a machine to act on that customer's behalf. The last row is the only thing ECZ-ID claims.
| Layer | What it does |
|---|---|
| IAM / IdPEntra ID, Okta, OAuth | Authenticates identities and issues tokens. |
| SIEM / SOARSentinel, Splunk | Collects telemetry and orchestrates response. |
| EDR / MDRDefender, SentinelOne, CrowdStrike | Detects and contains threats on the endpoint. |
| Gateways / orchestrationMCP gateways, workflow engines | Routes and executes machine calls. |
| ECZ-IDMachine Trust Register, Customer Authority, proof | ECZ-ID records identity, authority, delegation, state and evidence, and projects a proof your customer can check independently. |
What ECZ-ID is not
ECZ-ID does not replace your RMM, PSA, IAM, identity provider, OAuth, Entra, SIEM, SOAR, EDR, MDR, MCP gateway, workflow engine or orchestration platform.
- ECZ-ID does not execute anything in your customers' systems.
- ECZ-ID does not authenticate users or machines.
- ECZ-ID does not monitor, detect or alert on threats.
- ECZ-ID does not block, throttle or intercept a machine action.
- ECZ-ID does not manage endpoints, tickets, contracts or billing.
- ECZ-ID does not certify you as compliant with anything, and buying it does not make you compliant with anything.
This is the short list, stated plainly, because a governance product that is vague about its boundaries is indistinguishable from one that overreaches.
In an incident
Incident questions it answers, and the ones it does not
During the incident you are answering detection questions. Afterwards — in the review, on the insurer's form, in your client's board paper — the questions change shape. These four are the ones about authority, and they are asked about a specific point in time.
01
What machine held authority for this customer at the time in question?
Which agents, automations and integrations are associated with this client — named, with the identifier they carry in the system they run in.
Answered by · Machine Trust Register
02
Who authorised it, and when?
What this client has actually authorised, recorded separately from what a system happens to permit. A platform permission is not a customer's authority.
Answered by · Customer Authority
03
Was it revoked, when — and can the customer show that to a third party?
How fast the authority can be withdrawn, what state applies right now, and whether the withdrawal is something anyone else can confirm.
Answered by · Lifecycle state
04
What evidence was referenced, and by whom?
What was referenced, when, and by whom — kept so that what was true at an earlier time is still answerable later.
Answered by · Evidence references
What it does not answer
A technical reader will find these limits within an hour of using it, so they are stated here rather than discovered later.
- The detection question
- What executed, what was blocked, what the payload was and which host it touched are answered by your telemetry and your detection stack. This answers who was permitted to act for whom, on whose authority, and in what state. It is the authority question, and it is the only one being claimed.
- What actually happened
- A record that a machine held authority is not proof that the machine did anything. It is proof of what was authorised, by whom, when, and in what state. Anyone telling you an authority record reconstructs an incident is describing a product that does not exist.
- The period before the record existed
- State changes are recorded events with times and superseded records are retained, so the record answers what was true at an earlier time — from the first day it exists. It does not backfill. If the question is about a period before you began recording, this will not manufacture an answer.
The revocation drill
How fast can you turn it off, and who can independently verify you did?
Suspension and revocation are recorded events with a time, not a silent change to a permission somewhere. A revoked grant is terminal — it is never resurrected, and a replacement is a new record with a new identifier. Your client can check the current state themselves without asking you and without taking your word for it.
01
The question arrives
In a supplier questionnaire, on an insurer's proposal form, or at two in the morning from a client who has just read something. The wording varies; the question does not.
02
You suspend or revoke
Suspension pauses authority and is reversible — reinstatement is itself a recorded event, not a silent restore. Revocation withdraws authority and is terminal.
03
The change is recorded as an event, with a time
Not an untimed edit to a permission somewhere that has to be reconstructed afterwards from memory and screenshots.
04
Current state changes on that customer's record
The record carries one current state — active, suspended, revoked, superseded or expired — and the history behind it stays.
05
The customer re-checks independently
They open the proof themselves, without asking you and without taking your word for it. You are not in the loop, which is the whole reason their answer carries weight with the person who asked them.
06
Revocation stays revoked
A revoked grant is never resurrected. A replacement is a new record with a new identifier, so the earlier position remains answerable rather than being overwritten.
What the drill is not
Withdrawing authority in ECZ-ID does not disable a token, terminate a session, remove a role or stop a running process. Those are actions in your identity provider, your gateway and your endpoint tooling, and you carry them out there. What ECZ-ID does is record that authority was withdrawn, when and by whom, and put that in front of the customer to check for themselves. Treating the record as the kill switch would be a mistake, and we would rather say so here than have you find out during the drill.
| State | Meaning | Reversible | Rule |
|---|---|---|---|
| ACTIVE | Authority stands and the machine actor may act within it. | Yes | Can be suspended or revoked at any time. |
| SUSPENDED | Authority is paused. Nothing is deleted and the history stays. | Yes | Reinstatement is a recorded event, not a silent restore. |
| REVOKED | Authority is withdrawn. | No | Terminal. A revoked grant is never resurrected — a new grant is a new record with a new identifier. |
| SUPERSEDED | A newer grant replaced this one. | No | The superseded record is retained so that what was true at an earlier time is still answerable. |
| EXPIRED | The grant reached the end of its term. | No | Expiry is recorded as an event with its time, not inferred from a missing row. |
Regulated customers
When your customer is the one in scope
Often you are not the regulated party — your customer is. The way their obligation reaches you is a question, in writing, with a deadline, addressed to the provider holding privileged access to their estate.
In force · verified 2026-08-13
Under Article 21(3) of the NIS 2 Directive (Directive (EU) 2022/2555), essential and important entities must, when considering which supply chain security measures are appropriate, take into account the vulnerabilities specific to each direct supplier and service provider, and the overall quality of products and cybersecurity practices of their suppliers and service providers.
The duty falls on the in-scope entity and applies through national transposing law. Article 21(3) does not itself bring a supplier into scope — but note that Annex I lists managed service providers and managed security service providers as a sector of high criticality, so an MSP may be in scope in its own right under Articles 2 and 3.
Our reading, not the Directive's words. When a client of yours is in scope, that consideration becomes a question they send to you. Answering it is evidence work, and today it is usually unbilled.
Source: Directive (EU) 2022/2555, Article 21(3), Official Journal L 333/80, 27.12.2022
Answering that question well is evidence work: the machine actors named, the authority behind each one, the state that applies now, and something the person asking can check for themselves rather than file on trust. That is the artefact this produces, and it is the same artefact whether the request came from a regulator's transposing law, an insurer, or a client's largest customer.
Nothing in Article 21(3) names a product, nothing on this site is a legal opinion, and buying ECZ-ID does not make you compliant with anything. What it gives you is a record you can hand over and they can verify.
Next
Start with the check, not with a conversation.
The Machine Trust Check asks about the machine actors operating across your client estates and returns findings, not a score. If there is nothing to record yet it will say so, and that is a real answer rather than a reason to book a call.
What accepted partners begin with
Accepted partners begin with a £395 Client-Estate Machine Trust Audit. It is the first working step of the relationship, not a report you buy and file.
You buy at partner terms and set your own retail price. Terms are agreed in writing with each founding partner rather than published.
How access works
There is no countdown, no seat count and no waitlist number. The criteria are published above; if you meet them, apply.