Y6.04.4Qualification-aware access controldesignresearch

Systems should automatically restrict access when qualifications expire

Aliases: competency-based access control · qualification gating · break-glass access

What it is

Qualification-aware access control checks person, task, equipment configuration, and current qualification validity when authorizing action, blocking, reducing, or supervising mismatched high-risk work. It is a final gate, not a substitute for training management — it assumes the underlying qualification records and recertification intervals are accurate, and its only job is to enforce that existing judgment at the moment an action is actually attempted.

Why it happens

Manual review of qualification status gets missed in high-turnover, rotating-shift environments not because supervisors are careless, but because the check itself has no reliable trigger — it depends on someone happening to remember to look, which hands a systemic risk to individual memory.

Wiring the qualification database directly to the access-control system, so a qualification-status change automatically becomes a permission change, turns "forgot to revoke access" from a management lapse into something the system makes structurally impossible — nobody has to remember to check, because expiry itself is the trigger that revokes access. But getting this right requires the synchronization to be event-driven: a qualification change should trigger an immediate permission recalculation, not wait for a periodic batch sync. If the two systems are maintained independently and reconciled only once a day or once a week, there is a synchronization lag window in which a qualification has already expired but the access-control system has not yet been updated — old permission remains valid inside that window. Automation here has not removed the risk; it has only traded "a person forgot to check" for "the systems have not synced yet."

Studying it

Test four scenario classes — expired qualification, wrong equipment configuration, identity-service outage, and emergency response — measuring correct blocks, false denials (blocking something that should have been allowed), bypass attempts, time to recover from a fault, and whether every override is fully logged. Safety evaluation has to weigh both kinds of risk at once: unauthorized action, and delayed legitimate response caused by the block itself. Optimizing only for stricter blocking pushes risk to the other side of that trade-off.

Where it stops holding

Certain actions needed to move a system to a safe state must remain available to anyone present, unblocked by qualification gating — if the one person who holds the relevant qualification happens to have just lapsed and the site needs immediate action, the system needs an auditable temporary-authorization exception (two-person confirmation, or on-shift supervisor authorization, with a defined scope and time limit) rather than letting the automatic restriction itself become a new source of risk in that moment. Preventing unauthorized action and preventing delayed legitimate response are two goals that both have to be satisfied; a gating mechanism that only serves the first can create the second.

Observation and learning access can be separated from actual control access and need not carry the same gating strictness. Who is entitled to grant emergency authorization is determined by law and organizational governance; the system and its interface cannot invent a qualifying standard of their own to replace those rules.

Applying it

  • Bind permission to a specific action and the current equipment configuration; warn the person and their shift supervisor well before expiry, rather than letting access fail without warning mid-shift.
  • When access is restricted, state the specific reason, the exact steps to restore it, and which safe actions remain permitted — not just a bare "access denied" that leaves the operator with no next step.
  • Provide an auditable emergency-authorization path — two-person confirmation or on-shift-supervisor authorization — scoped to specific actions, time-limited, expiring automatically, and subject to mandatory post-hoc review.
  • Test synchronization lag between the qualification database and the access-control system, identity-service outages, and a scenario where a qualification lapses right as an emergency response is needed, checking that the system neither lets unauthorized action slip through nor locks out the one person who can address the emergency.

Related

  • Same group: Y6.04.1 Qualification must match the equipment version actually operated · Y6.04.2 Recertification intervals should follow skill-decay rates, not fixed years · Y6.04.3 Training records must be traceable for accident investigation
  • Nearby: O3 Authentication and authorization · Y4.07 Reachability and inadvertent activation of emergency controls
  • Search terms: qualification-aware access control · competency-based authorization · break-glass access

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y6.04.4