Electronic Key Cabinets: Audit Trails and Access Control NZ

Choose an electronic key cabinet by the key-control process it must support: who may collect each key, how collection and return are recorded, who acts on an overdue key, and what happens during a fault. Then select capacity, authentication and any required software integration. A cabinet transaction records custody; it does not prove which door was opened or prevent a physical key being copied after removal.

Begin with a key register and a permissions matrix

List every controlled key or keyset, its purpose, responsible owner and the doors, vehicles or equipment it can operate. Identify master keys and other high-impact items separately. Avoid labels that reveal sensitive locations to anyone who sees a misplaced tag. Keep the register accurate when locks or responsibilities change.

Define permissions at key level. A contractor permitted to enter the building should not automatically be able to collect a master key. Separate ordinary users from people who can create users, amend permissions, release keys exceptionally or delete information. Shared user codes weaken the ability to attribute a collection to a person.

Document who approves access and who reviews it. A useful matrix shows the person or role, permitted keysets, any operating restrictions, approval owner and review date. Treat these as project requirements to demonstrate on the proposed cabinet, not features guaranteed by every electronic model.

Specify the audit trail you actually need

For each issue and return, define the information the operator must retrieve: user identity, key identity, transaction type, timestamp and current custody state. Ask the supplier to show a report containing a complete collection and return cycle. Check how exceptions appear and whether the report remains understandable after a user or key name changes.

Choose a retention and export process around the organisation's needs. Decide who may read reports, where exports are kept and how administrators protect them. A cabinet audit contains staff activity information, so include it in the client's existing information-handling process rather than leaving exported files on an unrestricted shared drive.

Check the cabinet clock and the source of its time. If investigators need to compare key activity with access-control events or CCTV, timestamps must be understandable across systems. Do not describe several independent logs as one integrated audit trail unless the proposed solution actually links and identifies those events.

Turn overdue keys into an operational response

Define when a key should be returned and what makes it overdue. Some projects need an elapsed borrowing period; others need return before a shift ends. State whether a software reminder is mandatory, which recipient should receive it and what happens when that person is unavailable.

An alert only adds value when somebody owns the response. Set a contact sequence for checking with the borrower, confirming the key's location and escalating an unresolved exception. Where the chosen cabinet does not provide the required automatic notification, specify a documented manual review or choose equipment that demonstrably meets the requirement.

Test the whole workflow using an authorised test key and account. Record the expected trigger, observed report or notification, recipient and response. Avoid assuming that a function in a general software brochure is included in the quoted cabinet, licence and deployment.

Control contractor issue and return

Create a named contractor identity, confirm who sponsors the work and agree which keys are needed. Use supported expiry or schedule controls where specified and demonstrated. Otherwise, assign an administrator to remove permission at the agreed time. A temporary access requirement does not justify a permanent shared code.

Explain return procedures at induction. Identify where keys go after hours, who helps with a failed return and how the contractor reports damage or loss. Before closing the work order, reconcile the key register with the cabinet's actual status. A returned building pass does not establish that every physical key is back.

Keep a procedure for a key handed from one worker to another away from the cabinet. That handover can break the relationship between the electronic record and actual possession. Require an approved transfer record or a return and reissue process appropriate to the site's risk.

Compare Traka21 with a specified FERN360 solution

The Traka21 cabinet is a focused option for a standalone requirement. Traka documents 21 individually retained key or keyset positions. Its manufacturer specification describes PIN access, local administration, on-screen reporting and USB export, without a requirement for a network connection or PC.

That distinction matters. Do not specify Traka21 on the assumption that it includes the remote administration, web software or access-control integrations associated with other Traka platforms. If those functions are mandatory, identify the appropriate platform separately and obtain written confirmation of the proposed configuration.

The FERN360 key-management range provides another route for the equipment schedule. The FGKM-MK26 listing references API capability, while the FGKM-AS32 is a separate capacity candidate. Treat these as products to assess against the brief. Obtain the current model-specific specification, included software and interface documentation before promising a particular integration.

Compare the two routes on the actual job: standalone administration and local records may suit a small operation, while a project needing central workflows should demonstrate those workflows on the proposed networked configuration. Neither a brand name nor an Ethernet connector establishes the answer.

Make integration an acceptance test

Describe the required exchange in plain language. Does creating a staff member in the access-control system create a cabinet user? Does disabling that person remove permission to collect a key? Must the cabinet send collection events elsewhere, or does the requirement only call for a report export? These are different functions.

Require the supplier to identify the cabinet model, software edition, interface, firmware, supported partner version, licences and responsible integration contractor. Ask for API documentation where an API is proposed. An interface still requires supported software, mapping, authentication, testing and maintenance. Do not name RBH, Gallagher, ICT or another platform as compatible without evidence for that exact combination.

Test creation, modification and revocation using designated accounts. Include a failed connection, delayed change and recovery. Record whether local permissions remain active during an outage and how queued events are reconciled. The specification should identify who supports the interface after either system is updated.

Plan power, network failure and emergency release

Separate a cabinet power failure from loss of its network or management service. Determine which local functions remain available, how long the installed backup arrangement is designed to support them and how administrators recognise a fault. Test the agreed scenario rather than assuming that all offline behaviour is identical.

Traka's specification describes mains operation with optional battery backup and manual emergency release functions. Confirm what is actually included in the supplied Traka21 package. Optional backup must not be treated as a fitted battery or a measured runtime. Obtain corresponding written operating and recovery procedures for any proposed FERN360 cabinet.

Keep emergency override credentials or physical release keys under a separate, controlled procedure. Record who may use them, how the use is witnessed where required and how custody is reconciled afterwards. An emergency release can bypass ordinary electronic issue controls, so the recovery procedure needs its own record. Do not rely on a cabinet as the only means of accessing life-safety equipment without an approved contingency.

Choose capacity and commission the complete process

Count independently controlled keysets, not just individual keys on a desk. Several keys on one ring may occupy one position but share one permission and one custody record. Split sets where different staff need different entitlements. Check key-ring bulk, fob attachment, physical clearance and secure mounting as well as nominal slot count.

Allow for the client's stated growth rather than an arbitrary spare percentage. As a hypothetical example, 18 current keysets plus six confirmed new vehicle sets require more than 21 independently retained positions. Decide whether one larger cabinet or separate units best fits location, permissions and reporting. Do not assume separate standalone cabinets share a database.

Commission an allowed collection, a denied collection, return, report retrieval, an overdue workflow and the approved failure scenario. Train the actual administrator and shift users. Reconcile every physical keyset at handover and record remaining defects. Use our security system commissioning checklist to organise the handover. This specification and the supplier's current model documents should define the cabinet acceptance tests.

Agree lost-key escalation before the first issue

When a key cannot be located, verify the last recorded borrower and check for an unrecorded handover or return problem. Inform the nominated security manager and record the affected doors, assets and operational impact. Removing a person's cabinet permission prevents a future collection where enforced; it does not revoke a physical key already outside the cabinet.

The responsible manager should decide whether temporary protection, a lock change, a cylinder change or another response is required, with the relevant security and locksmith specialists. Record the decision, recovered or replaced items and updated register. Keep the incident open until custody and protection are resolved, rather than closing it solely because an overdue alert has been acknowledged.

Frequently asked questions

Does an electronic cabinet prove which door a key opened?

No. It records supported issue and return transactions. Establishing door use requires separate evidence or a specifically supported and commissioned integration.

Does Traka21 need a network connection?

Traka21 is documented as a standalone system without a requirement for a network connection or PC. Its specification includes local administration and reporting with USB export.

Can a FERN360 cabinet integrate with our access-control system?

Verify the exact cabinet, software, interface and partner version. Request current documentation and demonstrate the required user, permission and event exchanges before treating the integration as supported.

What should happen if a key is lost?

Check custody records, contact the borrower and notify the responsible security manager. Assess the affected locks and assets, agree protective action and reconcile the register before closing the incident.

Send your equipment schedule and project requirements to Essential Security Supplies for help with product selection, a trade quote and the documentation needed for your specification.