Is Validate just another permissions check?

No. Permissions are one input. Validate weighs identity, authority, policy and context together, checks whether a required approval exists and is still valid, and does it before the consequence rather than afterwards.

What happens when a check is refused?

The action does not proceed, and the outcome comes with its rationale. The requester is informed, the policy owner is notified, and the check is recorded through Anchor.

Can Validate be bypassed in an emergency?

Emergency access is handled as its own governed pattern, such as a time-bound Relay session with multi-party approval and full audit, so the check is not silently skipped.

Where does Validate sit relative to the application?

Ahead of the consequence: before access is granted, before an action is executed and before a transfer leaves the protected environment, using read paths the system being checked cannot silence.

FV-05 ValidateControl module · Protect the asset

Check who, why and with what authority. Before anything changes.

Validate confirms identity, authority and purpose before a path opens, an action runs or a protected asset moves. If any check fails, nothing changes, and the attempt is recorded.

Book a Control demo See it in action

ValidateProtect the asset

Module: FV-05 Validate
Family: Protect the asset
The question it answers: Should this request be allowed?
Checks: Identity, authority, purpose
If a check fails: Nothing changes

What happens when

The password was correct. The person was not.

Most access decisions rest on one thing: a login that works. Stolen logins work too.

MondayA login is stolen.
A convincing email captures an administrator password.
TuesdayA request is made.
Someone asks to open a path to the finance network. The password is accepted.
WednesdayNobody asked why.
There was no check of authority or purpose, so the request looked normal.

A password proves someone has it. Validate checks they should be doing this.

See it in action

One request. Switch between a password check and Validate.

The same request to open a path to finance, handled two ways.

Password onlyWith Validate

A correct password is enough to open the path.

Identity, authority and purpose are each checked. If any fails, the path stays as it is.

Step by step

Step 1Request
A person or system asks for a change.
Step 2Identity
Confirm who is asking, beyond a password.
Step 3Authority and purpose
Confirm they may ask, and that the reason matches an approved purpose.
Step 4Allow or refuse
The change happens only if every check passes. Both outcomes are recorded.

What Validate is

A gate in front of every change.

Validate sits before Relay, Execute and Transfer, so nothing opens or moves on a password alone.

Identity
Who is asking, confirmed in more than one way.
Authority
Whether that person may request this change.
Purpose
Whether the reason matches an approved purpose.

What it changes

Stolen logins are not enough.

Validate does not stop credentials being stolen. It stops a stolen credential being the only thing needed.

Every change has a reason and an owner.

Changes need identity, authority and purpose
Failed checks change nothing
Refusals are recorded as well as approvals
Auditors see who asked, why and who allowed it

Where it fits

Fracture, Isolate and Validate answer different questions.

Fracture and Isolate decide whether connections exist. Validate does a different job, and most Plans use more than one module.

Module	Fracture	Isolate	Validate
The question it answers	Must this connection be physically disconnected now?	Which zones should never share a path?	Should this request be allowed, by this person, for this reason?
Normal state	Connected, with a crossing ready to be disconnected	Zones held apart, crossings closed by default	Every request checked before any change
When it acts	When a connection becomes dangerous	By design, before anything goes wrong	Before a path opens, an action runs or an asset moves
What it ends	An incident travelling along a live path	Trust that exists only because systems share a network	Changes made on the strength of a password alone
Typical Plans	CP-01, CP-02	CP-04, CP-05, CP-14	CP-06, CP-12, CP-20

Control Plans and Blueprints

Where Validate does the work.

Validate is the check behind access, assurance and multi-party Plans. Plans marked Proposed are awaiting technical approval.

Control PlansTwenty Plans, each solving one problem.All Control Plans
Control BlueprintsIndustry solutions that combine Plans.All Control Blueprints
FracturePhysically disconnect a connection.See Fracture
IsolateHold zones apart by design.See Isolate

Questions

What network and security teams ask.

Want to see it on real hardware? We will show you.

Book a Control demo

Does Validate replace our identity provider?

No. It uses the identity sources you already have and adds checks of authority and purpose before a Control change.

How is Validate different from Fracture and Isolate?

Fracture and Isolate work on connections. Validate decides whether a requested change should be allowed at all.

Can it require more than one approver?

Yes, where the risk warrants it. This is agreed per path or action.

What happens when a check fails?

Nothing changes, and the attempt is recorded.

Your next step

See a request checked in front of you.

We will show a request allowed, and the same request refused, with the record for both.

Book a Control demo