One Fob, One Name: Credential Control Across Multiple Trades on a Live Scaffold

The shared code problem

On a busy scaffold, the pressure to simplify is relentless. Four trades need to be on site before 7am. The site manager is not due until 8. Rather than manage twenty credentials, someone sets a single user code and circulates it. Within a fortnight it is on a WhatsApp group, a former operative still knows it, and nobody can say who disarmed the system on the night of the loss.

That is the operational failure mode this article addresses. Access control on a scaffold alarm does not have to be cumbersome, but it does have to be individual. The objective is straightforward: every person who can disarm or bypass any part of the system is identifiable, their permission is time-bound, and revocation is immediate and evidenced.

Start with the access model, not the hardware

Before selecting fobs or keypads, define who needs what. On a typical multi-trade scaffold site you will usually find four distinct groups:

• Full users—site management and the principal contractor's appointed person, who may arm and disarm the whole system.
• Partial users—trade supervisors who need access to a defined zone or a defined time window, and nothing more.
• Escort-only visitors—inspectors, clients, designers, who should be admitted by a full user rather than issued credentials at all.
• Response keyholders—individuals who attend out of hours and may need to disarm after an activation, but who should never be able to arm the system down for convenience.

Mapping these groups first prevents the common outcome where every credential issued is a master credential.

Hardware options and what each one buys you

Proximity fobs or tags. The strongest option for audit trail and revocation. Each fob is issued to a named individual, the panel logs the fob identifier against arm and disarm events, and a lost fob can be deleted without disturbing anyone else. Fobs are cheap enough to treat as consumables and to hold a deposit against.

Individual keypad codes. Acceptable where fobs are impractical—for example, on a panel mounted inside a protected enclosure with no reader. The essential rule is one code per person, never one code per trade. Where the panel supports it, enable a distinct duress code and a separate engineer code held only by the alarm company.

Time-limited or scheduled credentials. Increasingly available on networked panels, allowing a credential to work only between stated hours or only on nominated days. This is the single most effective control against the permanently disarmed system: if a trade credential cannot disarm the system between 18:00 and 06:00, the overnight armed state is not dependent on good behaviour.

Remote revocation and app-based management. Useful on larger or longer sites where the responsible person is not always on site. Ensure the audit log is exportable and that revocation events are timestamped and attributable.

Dual authorisation. For high-value sites, require two credentials to disarm outside working hours. It slows a legitimate keyholder by seconds and removes the single-credential risk entirely.

Induction-linked issuance

Credentials should be a product of induction, not a separate administrative process. The cleanest arrangement ties the two together:

1. Operative completes site induction, including a short briefing on the alarm, the perimeter, the zones and the consequences of tampering.
2. Induction record is signed and filed with the operative's name, trade, employer and expected duration on site.
3. Credential is issued at that point, logged against the induction reference, and handed over in person.
4. The operative signs for the credential, acknowledging that it is personal, non-transferable, and that loss must be reported immediately.

Where a deposit is taken for a fob, the return is recorded on demobilisation. The deposit is not primarily a financial control; it is a behavioural one that produces a return event you can audit.

An access register that actually gets used

The register is the audit trail. It should be a live document, not a sheet completed at the start of the project and abandoned. As a minimum it should record:

• credential identifier and type (fob, code, tag);
• holder's name, employer and trade;
• permission level and any zone or time restrictions;
• issue date, issuing person and induction reference;
• expected demobilisation date;
• revocation date, reason and the person who actioned it.

Review the register weekly against the site's actual labour returns. Discrepancies—people on site with no credential, credentials held by people no longer on site—are the signal that the regime is drifting.

Shift changes, weekends and shutdown periods

Most losses on scaffold sites happen outside core hours, and most credential leakage happens at the boundaries between them. Three habits close the gap:

• Shift-change sweep. At the end of each shift, confirm the system is armed and record the arm event. Do not rely on the panel's default auto-arm unless you have verified it is enabled and functioning.
• Weekend and holiday lockdown. Suspend trade-level credentials for the shutdown period, leaving only the designated response keyholders active. Reactivate on the first working morning.
• Leaver protocol. The same day an operative demobilises, their credential is deleted and the register updated. Waiting for the next weekly review is how a former employee retains access for six weeks.

Keyholder lists are credentials too

An unmanaged keyholder list is a security weakness in its own right. A list of nine names, none of whom is certain they are first call, produces delay and ambiguity at exactly the moment clarity matters.

Keep the list short—three to four names, in a defined escalation order, with at least one who lives within a realistic travelling distance of the site. Confirm each number by live call-back at handover and at each quarterly review. Record the response expectation in writing: who attends, within what period, and what they are authorised to do on arrival. Where the alarm is confirmation-based, make sure keyholders understand that the first notification may not be the alarm itself and that a call-back to the monitoring centre or a check of the zone log is part of the response.

The risks of getting it wrong

An unmanaged credential regime produces a predictable set of exposures:

• the system resting permanently disarmed because the last person out did not know how to arm it;
• a shared code that cannot be attributed to any individual after an incident;
• an insurer or client asking who disarmed the system and receiving no answer;
• a tamper event that is dismissed as a fault because nobody can say whether a credential was used;
• subcontracted labour carrying credentials across to a second site, where the same fob is accepted.

None of these require a sophisticated attacker. They are ordinary administrative failures with security consequences.

The one-page rule set

If the site needs a single sheet at the gate, make it this:

• One credential, one named person. No exceptions, including for supervisors.
• No credential is issued without an induction reference.
• Trade credentials do not disarm the system outside stated hours.
• Lost credential reported the same day; deleted the same day.
• Register reviewed weekly against labour returns.
• Keyholder list limited to four names, confirmed quarterly by call-back.
• Every disarm event attributable to a person in the log.

Closing the loop

Credential management is unglamorous work, and it is the part of a scaffold alarm installation most likely to determine whether the system is armed when it matters. A panel with excellent detection and a shared code is a system that reports honestly on intrusions it was never configured to resist. Individual credentials, time-bound permissions and a register that is reviewed rather than filed turn the same hardware into a defensible security control.