Two announcements inside two weeks say the same thing from different directions. On September 8, West Coast Self-Storage said it will standardize StorageDefender Smart Unit and Smart Zone monitoring across its portfolio of nearly 170 locations, rolling out through Q4 2026. Two weeks earlier, OpenTech Alliance signed a letter of intent to acquire SAM Systems, the manufacturer of an NFC smart latch lock, with a keyless option expected to land under $100 per lock and product availability projected for Q1 2027.
The direction is the same in both cases: the physical layer of a storage facility - the lock, the unit sensor, the keypad - is turning into subscription software. And most operators are still evaluating it like hardware.
For most of this industry's history, the physical layer was the one part of the stack you could ignore in a systems conversation. A lock was a padlock the tenant bought at the counter. A gate keypad talked to whatever access software you ran, and if you changed property management systems, nobody had to touch a single door. Hardware was a capital purchase, bought on price and durability, replaced when it rusted.
That model is ending. A smart latch lock is an endpoint on a vendor's platform. A unit sensor reports motion, temperature, and humidity into a vendor's cloud, and the tenant-facing subscription that pays for it runs through the vendor's billing. The keypad authenticates against the vendor's access service. None of these devices is useful on its own. Each one is the physical tip of a software relationship - usually priced per unit per month, and increasingly sold to you as an ancillary revenue stream rather than a cost.
Here is the problem, and it is not the technology. It is the mismatch between two clocks.
Two clocks that do not match
Software runs on a short clock. You sign for a year or three, and if the product disappoints, migration is painful but bounded - export the data, retrain the staff, cut over. The industry knows how to do this.
Hardware runs on a long clock. A lock or a sensor gets installed on every door of every unit at every site, and it stays there for a decade or more, because the replacement cost is not a license fee - it is truck rolls multiplied by doors multiplied by sites. When you screw a vendor's device into 15,000 doors, you have not made a software decision with hardware attached. You have made a hardware-length commitment to a software company.
That is the real meaning of a platform vendor acquiring a lock manufacturer. The consolidation is not sinister - it is rational, and it will keep happening. But every acquisition like it shrinks the pool of hardware that works independently of any one platform, and pulls the physical layer deeper into ecosystems that are priced, updated, and sunset on software terms.
To be fair about the other side of the trade: there are real gains here, and I would take some of them. One vendor accountable for the whole access path beats three vendors pointing at each other when a tenant is locked out at 9pm. A sub-$100 smart lock puts unit-level access within reach of operators who could never justify it at previous prices. Tenant-paid monitoring is genuine revenue, not vapor. And West Coast standardizing one monitoring layer across a portfolio running different systems is the right instinct - a mixed-acquisition portfolio converging on one system per function is how you get out of fragmentation. The move itself is sound. The underwriting is where operators get sloppy.
Underwrite it properly
So underwrite it properly. Four things I would put in front of any smart hardware decision this year:
Underwrite on the hardware clock, not the contract term. The question is not whether you like this vendor for the next three years. It is whether you accept living with them for the life of the device on the door. Price the exit while you still have leverage: what does it cost, in labor and hardware, to take it all off again?
Ask the lapse question, in writing. What does the lock do the day the subscription stops? Is it still a lock, or is it a brick with an antenna? What does the sensor data do - does it degrade to nothing, and does your history come with you? A vendor confident in the product will answer this on paper. A vendor who will not has answered a different question.
Count the revenue dependency. The ancillary revenue framing is the cleverest part of the pitch, and it cuts both ways. Once tenant monitoring fees are a line on your P&L, replacing that vendor is no longer an IT project - it is a revenue event. You are not just switching a supplier. You are unwinding an income stream your budget has already absorbed.
Claim the data. Unit-level activity is operational data about your property and your tenants. Know where it lands, who owns it, and whether you can pull it out at full fidelity without the vendor's help. If the answer is no, the monitoring layer is not reporting to you - you are reporting to it.
The access layer used to sit outside the architecture conversation. As of this quarter, it belongs inside it, next to the PMS and the payment stack, with the same scrutiny. When I map a target-state architecture for an operator, the question is never whether a given tool is good - it is what the operation depends on, for how long, and on whose terms. The physical layer just joined that list.
That is the kind of dependency a Blueprint maps - what your operation runs on, for how long, and on whose terms. Better to see it before you commit every door than after.
Start with a Blueprint