Recent Breaches
Breaches
View All →
Control Module - VAULT

FV-Lock. Access governed as one coherent layer.

Lock restricts access through identity, authority, policy, permission and operational controls. Each of these matters on its own, but the protection comes from treating them as one coherent layer rather than five disconnected ones.

Back to Control

Control Module - VAULT

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

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

The Problem

Access controls that disagree with each other quietly grant everything.

Fragmented enforcement

When identity, policy and operational controls live in different places and tools, the disagreements between them tend to resolve in favour of access.

Permissions without authority

A user may hold a permission, but without the authority to use it in the current context, the permission alone is not enough to justify the action.

Standing privilege

Privilege that exists permanently is privilege that can be abused permanently, by anyone who reaches the account or the session.

The Scenario

Scenario: a permitted user, the wrong moment

An administrator who holds the necessary permission attempts a sensitive operation outside the approved change window. Identity and permission both check out, but the operational controls do not, because the change window is closed. Lock refuses the operation, returns the rationale and notifies the policy owner. The administrator schedules the work for the next window and the operation proceeds in its proper place.

"Lock is what stops a yes from being the answer to the wrong question."

FV-Lock in placement

Where Lock enforces named, scoped access.

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.

Inputs ─┐Telemetry ─┐

FV-Lock

Control layer

┌─ Outputs┌─ Control
01SR 2.1

Privileged operator sessions

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

02A.5.15

Vendor maintenance accounts

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

03A.8.2

Crown-jewel data access

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

04PR.AC-4

Emergency break-glass

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

Relies on · prerequisites

  • 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

Pairs with · companion modules

RelayExecuteUnlinkValidate

Featured In

TechRadar ProSecurity BuyerYahoo FinanceSecurityBriefChannel Insider

Key Capabilities

Identity as the first clause

Who is asking is established before any other clause is evaluated.

Authority as the second

The authority under which the request is made is treated as a first-class input.

Policy as the third

The policy of the moment, including its exceptions and constraints, is part of the evaluation.

Permission as the fourth

Permissions are necessary but not sufficient, and are evaluated against the other clauses rather than alone.

Operational state as the fifth

Operational controls reflect the current state of the environment, so an answer that suits one moment is not assumed to suit another.

Evidential record

Outcomes and rationales are recorded through Archive on physically separate storage.

Demo to Live

Adoption Guide

Step 1

Map the access surface

Identify the access decisions that matter, the identities involved and the policies that apply.

Step 2

Define the five clauses

For each decision, agree the identity, authority, policy, permission and operational expectations.

Step 3

Pilot a coherent decision

Move one workflow onto Lock end-to-end, with the rationale returned to the requester.

Step 4

Operate and review

Extend Lock across further workflows and review patterns through Archive on a regular cadence.

Step 1

Map the access surface

Identify the access decisions that matter, the identities involved and the policies that apply.

Step 2

Define the five clauses

For each decision, agree the identity, authority, policy, permission and operational expectations.

Step 3

Pilot a coherent decision

Move one workflow onto Lock end-to-end, with the rationale returned to the requester.

Step 4

Operate and review

Extend Lock across further workflows and review patterns through Archive on a regular cadence.

Questions

Frequently Asked

    Lock

    Access governance and dual-control module for OT environments.

    © 2026 Firevault Limited. Disconnect to Protect®