Control module · Vault layer

FV-Lock. Access governed as one coherent layer.

Lock restricts access through identity, authority, policy, permission and operational controls. It treats those five controls as one combined layer rather than five separate ones, and that combination is where its protection comes from.

Schedule a demo Back to Control

As featured in

The problem

Access is a sentence with five clauses.

Access is a sentence with five clauses. Lock reads all of them before answering.

The requester’s identity is established before any other clause is evaluated.
The authority behind a request is treated as a core input.
Operational controls track the environment’s current state, so an approval for one moment does not carry over to another.

Problem 1

Fragmented enforcement.

When identity, policy and operational controls sit in separate places and tools, conflicts between them usually end up granting access.

Answered byIdentity as the first clause

Problem 2

Permissions without authority.

Holding a permission is not enough on its own. Without authority for the current context, it does not justify the action.

Answered byAuthority as the second

Problem 3

Standing privilege.

Permanent privilege can be misused indefinitely by whoever gets into the account or session.

Answered byOperational state as the fifth

The scenario

Scenario:
A permitted user, the wrong moment.

Lock is what stops a yes from being the answer to the wrong question. Step through it, or play it through.

Step 1 of 4

Attempt

An administrator who holds the necessary permission attempts a sensitive operation outside the approved change window.

Illustration.

Identity: Who is asking, established before anything else
Authority: Under whose authority the request is being made
Policy: What the policy of the moment actually allows
Operational: Controls that reflect the state of the environment

Schedule a demo Back to Control

Placement

Where Lock grants reach as a named event.

Lock turns access from a long-lived right into a named, scoped event. Reach is granted to a person, for a purpose, for a window, and recorded. Grounded in NIST CSF PR.AC-1 and PR.AC-4, ISO 27001 A.5.15, A.8.2 and IEC 62443-3-3 SR 1.1, SR 2.1.

Relies on

Reliable identity for the named actor
Scope that is narrower than the access path can technically allow
Recorded purpose for each grant, not just the grant

Schedule a demo See the Firebreak® range

Pairs with

FV-Lock works alongside Relay, Execute, Unlink and Validate. Firebreak® hardware is manufactured by Firevault.

All Control modules

IEC 62443 SR 2.1

Privileged operator sessions

Administrative reach into protected zones is granted per session, per person, with explicit scope.

ISO 27001 A.5.15

Vendor maintenance accounts

Vendor identities are locked to a named engagement. No shared, evergreen credentials.

Physically disconnected Offline Secure Storage: server, three drives and a padlock

ISO 27001 A.8.2

Crown-jewel data access

Sensitive datasets are reachable only by named requestors through an approved Lock event.

NIST CSF PR.AC-4

Emergency break-glass

Emergency access is a Lock event with quorum approval, full audit and a hard expiry.

Capabilities

What you get with every deployment.

Six things FV-Lock gives a security team, from the first decision to the audit afterwards.

FV-Lock

Identity as the first clause

The requester’s identity is established before any other clause is evaluated.

FV-Lock

Authority as the second

The authority behind a request is treated as a core input.

FV-Lock

Policy as the third

The policy in force at the time, including exceptions and constraints, shapes the decision.

FV-Lock

Permission as the fourth

Permissions are needed but not enough on their own, so they are checked alongside the other clauses.

FV-Lock

Operational state as the fifth

Operational controls track the environment’s current state, so an approval for one moment does not carry over to another.

FV-Lock

Evidential record

Outcomes and reasons are logged through Archive on physically separate storage.

Adoption guide

From first workflow to routine operation.

Four steps, piloted on one workflow before it extends across the estate.

1
Map the access surface

List the access decisions that matter, the identities involved and the applicable policies.
2
Define the five clauses

Agree the identity, authority, policy, permission and operational expectations for each decision.
3
Pilot a coherent decision

Run one workflow end-to-end through Lock and return the reasoning to the requester.
4
Operate and review

Expand Lock to more workflows and review decision patterns through Archive on a regular schedule.

Playbooks

Which playbook covers this module.

Each playbook shows where this module sits in a real deployment, who authorises it and how a pilot scales into rollout.

The Leaders’ Playbook

Covers authority, custody and succession, including who can open what after a change of control.

Read the playbook

Close the File. Protect the Record.

Covers permission, supervision and client confidentiality duties for retained records.

Read the playbook

All playbooks

Explore more

Where to go next.

Questions

Frequently asked about Lock

Identity is Lock’s first clause, not the whole decision. Lock reads identity alongside authority, policy, permission and operational state, and answers as one coherent layer.

Emergency break-glass is a Lock event with quorum approval, full audit and a hard expiry.

The same way as people: reach is granted to a named actor, for a purpose, for a window, with scope narrower than the access path can technically allow, and a recorded purpose for each grant.

Every outcome and its reasons are logged through Archive on physically separate storage, and decision patterns are reviewed on a regular schedule.

All questions

Decide what stays connected.

We will walk your architecture, show where FV-Lock sits on each path, and the evidence it leaves behind.

Book a demo Speak to the team

Schedule a demo Control

FV-Lock. Access governed as one coherent layer.