Specifying Smart Locks in Construction Documents: Basis of Design, Submittals and Closeout

—

A smart lock sits where several trades meet. The door hardware supplier provides the lock, the electrical contractor may provide power, the security or IT contractor may provide the network and the management system, and the owner’s staff will run it for years. A specification that leaves a gap between those scopes tends to reveal it at handover, when nobody’s contract includes setting up the accounts or connecting the gateway.

The decisions that close those gaps belong in the construction documents, before the hardware is bid. This article uses one published master specification as a running example: the University of Houston’s Section 08 71 00 Door Hardware. Where it is cited, the requirement is the university’s; the smart-lock additions around it are suggestions to adapt.

Where a SivoLock lock is considered as the basis of design, identify the proposed model and document the door interface, power, access method and submittal requirements. That gives the project team a defined proposal to coordinate and a consistent basis for assessing alternatives.

Decide Who Supplies, Installs, Configures and Verifies

Door hardware sections commonly carry the lock, while access control systems sit in the electronic security sections of Division 28. The Houston specification, for instance, assigns access control devices installed at openings as part of a security system to a Division 28 section. An article in The Construction Specifier described the coordination problems that arise when door hardware sections are used for work that crosses into Division 28, and the timing problem behind them: the door hardware section may be bid earlier than the security work. One proposal in that article is a door hardware schedule with a column that names the section responsible for each component of the opening.

For smart locks, one responsible party per component is often not enough, because supplying a part, installing it, configuring it and verifying it may fall to different parties. Take a gateway that links the locks to a management platform. In one possible arrangement:

The parties will differ from project to project. What matters is that every cell names one, and that each section states what it assumes the others provide. Add rows for power supplies, network connections and programming as the project needs.

Define the Basis of Design and the Requirements for Alternatives

A specification can name a basis-of-design product and still set requirements that any product must meet. The Houston specification names basis-of-design products, allows comparable products from listed manufacturers, and refers substitutions to the Division 01 procedures. Whatever the arrangement, keep four things distinct: the reference product, any listed acceptable products, substitutions that need approval, and the criteria used to judge an alternative.

Those criteria are where smart locks need the most care. In US federal procurement, FAR 11.104 says that a “brand name or equal” description must include a general description of the salient physical, functional or performance characteristics an equal item has to meet, and that such descriptions are used when those characteristics are firm requirements. Private projects follow their own substitution procedures, but writing the characteristics down is what makes an alternative possible to judge. For a smart lock, they usually include:

• Door compatibility: the door type, thickness range, lock body and backset, and the preparation the doors will have.
• Access methods: the credentials required on each side, such as card technology, PIN, mobile credential or biometric.
• Power: battery or wired, the low-battery warning and the emergency power or override method.
• Operation without the network: which functions must keep working locally when the network or platform is unavailable, and how changes such as a revoked credential reach a lock that is offline.
• Management: the platform, integrations required with other systems, user roles, and event records.
• Environment and finish: ratings for exterior or wet locations, and the finish and material of exposed parts.
• Standards and evidence: the BHMA standards, editions, product categories and grades the project requires, and the evidence for each: a test report, a manufacturer’s declaration of conformity and third-party certification are different things. BHMA’s A156.25 covers electrified locking systems, testing their electrical operation alongside the mechanical BHMA standard for the lock type. Do not read it as evidence about the app, the cloud platform or cybersecurity; specify those separately.
• Software support: the security update period the manufacturer commits to, and how updates are delivered.

 
Keep the list to firm requirements. Every characteristic that is only a preference narrows the field of alternatives without protecting the project.

Handle the Decisions That Are Not Made Yet

At bid time, the owner may not have chosen a management platform, or may still be deciding whether some doors join the building’s access control system. An allowance can carry the cost of the undecided work, and an alternate can price a defined option, such as a stated group of doors connected to the access control system, as long as it describes a complete option that bidders can price. Neither settles whether the hardware will work with the platform eventually chosen. Where the platform affects the communication method, gateways, credential technology or controllers, resolve those interfaces before the affected hardware is ordered.

Ask bidders to price software subscriptions and platform licenses separately, for a stated number of years, so the bids cover the same period. Require the owner’s IT team to review the platform’s hosting, data location and retention, and account structure as part of submittal review, before the hardware is released for ordering.

Tie Special Openings to Their Operation

Fire-rated doors, doors on exit routes and doors on accessible routes need more than a hardware submittal, and the reviews differ in kind. A fire-rated opening needs evidence that the lock is permitted on the rated assembly as specified and installed. An exit door needs its egress operation confirmed. An accessible door needs its operating hardware checked against the accessibility requirements that apply. For each of these openings, the operation narrative should state:

• normal entry and exit;
• what happens during a power, network or platform failure;
• any fire alarm interface and the response required, where one applies;
• the evidence that covers the specified assembly and installation;
• who checks it, and at what stage.

 
Carry the same items into the commissioning demonstration for those openings.

Ask for Submittals That Show What Will Be Installed

A typical door hardware specification already asks for product data, samples of exposed finishes, and a door hardware schedule. The Houston specification also requires the schedule to use the same door numbers as the contract documents, and shop drawings for electrified hardware with wiring diagrams and an operation narrative. For smart locks, add:

• Platform data: the software platform and version, where it is hosted, and the account structure.
• A credential and user plan: the smart lock equivalent of a keying schedule, showing user groups, access levels and who enrolls them.
• Security documentation: the security update period, how vulnerabilities are reported, and the default password policy.
• Battery and maintenance data: battery type, expected replacement process and low-battery behavior.
• Evidence for the standards and ratings the specification names, identified as test reports, declarations or certificates.

Write the Expected Results Before Commissioning

Use the preinstallation conference to walk through the responsibility table with every trade, and to confirm electrical rough-in where locks are wired. Require the first installation of each door type to be checked before the rest proceed.

A demonstration proves something only if the expected result is written down first. State, for example, how and when a revoked credential stops working at a lock that is offline, including any synchronization it needs, then test that behavior. Do the same for valid credentials, locking and relocking, the local fallback when the network is unavailable, and the special openings. For low-battery and fault conditions, agree a method with the manufacturer, such as a test mode or a demonstration on selected doors, rather than draining batteries or disrupting every opening. Record the results against each opening in the hardware schedule.

Spell Out Closeout

Closeout is where gaps in the specification become visible. Require:

• Maintenance data, including the final hardware schedule as installed, with lock versions and firmware recorded.
• The credential and user plan as handed over, showing user groups, access levels and the administrators.
• Account handover: before acceptance, the owner’s administrators log in, manage users and complete an account recovery. Installer and supplier access is removed, or kept to a stated scope and period under the support agreement.
• Controlled transfer of secrets: no PINs, passwords or encryption keys in plain text in the ordinary closeout documents; hand them over by a method agreed with the owner.
• Training for the owner’s staff. The Houston specification requires a factory-authorized service representative to train the owner’s personnel on door hardware.
• Extra materials: spare credentials, batteries and any modules the owner wants on the shelf, labeled and matched to the installed version.
• A follow-up visit, if the project includes one. The Houston specification calls for an occupancy adjustment about six months after Substantial Completion. On a smart lock project, such a visit can also check battery levels and firmware versions, with event records reviewed only as far as authorized diagnostics need. It does not replace maintenance due before then.
• Warranty by component, with the software support period stated separately. The Houston specification sets different warranty periods for different hardware types.

 
Specification and procurement often run back and forth, as supplier responses raise questions that change the documents. For the procurement side, from the door schedule to the supplier’s response and commercial terms, see SivoLock’s smart lock project specification and RFQ guide.

References

1. Federal Acquisition Regulation: 104 Use of brand name or equal purchase descriptions
2. Katie Daniel: Remaking Division 28: Specifying electronic safety and security with MasterFormat 2016, The Construction Specifier, May 5, 2016
3. University of Houston: Section 08 71 00 Door Hardware, master construction specification (revised 2018)
4. Builders Hardware Manufacturers Association: ANSI/BHMA A156.25-2023 Electrified Locking Systems

FAQS

Which spec section covers smart locks?

Locks usually sit in Section 08 71 00 Door Hardware, while access control sits in Division 28. Use a responsibility table naming who supplies, installs, configures and verifies each component.

What should the criteria for alternatives include?

Door compatibility, access methods, power and emergency override, offline operation, management platform, environment and finish, standards and evidence, and security update period.

Does BHMA A156.25 cover the app or cybersecurity?

No. It covers the electrical operation of electrified locking systems alongside the mechanical standard. Specify app, cloud and cybersecurity requirements separately.

—

This content is brought to you by Prime Star

iStockPhoto