When the contractor borrows a key – and the log names the wrong person
Lending keys destroys traceability. See how controlled key sharing with master keys, sharing keys and individual shares gives contractors access without losing track of who actually walked in.
It is Saturday. A valve is leaking at a pumping station. The contractor needs to get in now, and the only person with access is an operations manager sitting at a family party.
So everyone does what everyone does: the manager passes on the code, lends out the key, or hands over his phone.
The problem does not appear on Saturday. It appears three months later, when somebody looks at the log and sees that the operations manager opened the pumping station at 14:32 on Saturday. He was 80 kilometres away.
What lending actually costs
Traceability disappears
The log points at a person who was not there. Every downstream record is now wrong.
Access never expires
The job took three hours. The access lasted until somebody remembered to withdraw it – if anybody did.
The master key is too big
The contractor needed one room. He got access to everything the master key opens.
The supply chain cannot be evidenced
NIS2 requires management of supplier access. "He borrowed a key" is not management.
The model: master key, sharing key, share
Rather than banning sharing — which merely moves it outside the system — SnapKey makes sharing something that can be governed and seen.
There are three concepts, and the distinction between them is the whole point:
| Concept | What it is |
|---|---|
| Master key | The original access a person holds |
| Sharing key | The template that permits sharing – it defines what may be passed on |
| Share | One actual handover to one specific person |
So the operations manager cannot simply hand his access onward. He can hand on what the sharing key permits — and each time he does, it becomes a recorded share with a sender, a recipient and a period.
Master key (operations manager)
│
└─ Sharing key: "Pump house 2, weekdays 07–18" ← the template
│
├─ Share → Contractor A Sat 12:00–18:00 [active]
├─ Share → Contractor B Mon 08:00–16:00 [expired]
└─ Share → Temp C (no answer yet) [pending]
Every share has a state
A share is not simply on or off. It has a lifecycle, and the state tells you what actually happened:
✅ Pending – sent, but the recipient has not responded
✅ Accepted – the recipient took it up
✅ Active – in force right now
✅ Rejected – the recipient declined
✅ Expired – the period ended and the access fell away by itself
✅ Revoked – somebody withdrew it early
The difference between rejected and expired is worth noting. The first means the access was never used. The second means it worked and then stopped. Both are documentation — but they do not document the same thing.
The recipient does not need an account first
A contractor who has never been there before has no user account. The share can still be created: the recipient's details are captured when the key is shared, and the person shows as not registered until they sign up.
That detail decides whether the system gets used on a Saturday afternoon — or worked around.
Two ways to look at it
Shares – a list of every individual handover: who shared, who received, which master key it came from, for which period, and what happened.
By master key – the tree from above: here is the master key, here are the sharing keys it permits, and here is every share that came out of them.
The second is what you use to answer the uncomfortable question: how many people can, in practice, open that door? The number is almost always higher than anyone expects — and with a physical key cabinet it cannot be established at all.
Revoking without touching the master key
To stop a contractor's access immediately, you revoke the share. The master key is untouched, and the other shares continue undisturbed.
Compare that with the mechanical reality: to make one issued key useless, you rekey the cylinder — and then everyone else's keys have to be replaced too.
What this means for NIS2 and CER
NIS2 requires supply chain security: you must assess and manage risks from suppliers and partners. CER requires preventive measures and evidence of who has had access to critical functions.
Controlled sharing answers the questions supervision asks about external parties:
| Question | Answer |
|---|---|
| Which external parties had access this year? | The list of shares for the period |
| Who granted the access? | The sender is recorded on every share |
| How long did it last? | The period on the share – and it expired on its own |
| Did they get more than they needed? | No – the sharing key bounded what could be passed on |
| So who opened the door? | The recipient, with her own key. Not the operations manager. |
That last line is the whole difference. Once the contractor has her own access instead of a borrowed one, the log finally points at the person who was actually standing at the door.
FAQ
What is the difference between a sharing key and a share?
The sharing key is the template that permits sharing and bounds what may be passed on. A share is one specific handover to one person for one period. A single sharing key can give rise to many shares.
Can we share with someone who has no account?
Yes. The recipient's details are captured at the point of sharing, and the person shows as not registered until they create an account.
Can a recipient share onward?
Only if permitted through a sharing key. Without one, a received access is exactly that – an access, not a right to pass it on.
What happens when the period ends?
The access ceases by itself and the share is marked expired. There is no key to collect and no cylinder to rekey.
Can we see how many people can actually open a given door?
Yes. The by-master-key view shows the whole tree – the master key, the sharing keys it permits, and every share that came out of them.
Contact us
Should contractors be able to get in without destroying your traceability? Contact SnapKey.
Related articles
Energy Legislation and Access Control – Requirements for Critical Infrastructure
Understand energy legislation requirements for physical security and access control. Learn how SnapKey helps energy companies achieve compliance.
From incident to regulatory report in 24 hours – without guessing
NIS2 gives you 24 hours for an early warning. See how an access incident is recorded automatically, escalated into a regulatory case and filed on time – with countdowns, PDFs and an unbroken chain of evidence.
NIS2 Directive – Access Control and Cybersecurity Requirements 2025
The NIS2 law introduces enhanced requirements for cybersecurity and access control for businesses in critical infrastructure. Learn about the new requirements and how to achieve compliance.