Unlock the full potential of Wavestore v6.48 -view our launch presentation today and explore the latest innovations in video management.
Most unified security platform evaluations produce the same result: a folder of RFP responses that all claim the same capabilities, a shortlist of vendors whose demonstration environments look identical, and a selection decision that comes down to price and relationship rather than architectural reality.
The questions that actually differentiate platforms — what happens when the WAN goes down, how licensing compounds as the team doubles, whether the integration between video and access control is native or middleware-dependent — are almost never in a standard evaluation script. Vendors know this. Demonstration environments are configured accordingly.
This guide gives procurement leads a structured framework for running a unified security platform evaluation that finds the architectural differences that matter. For the background on what a unified platform should actually deliver, see our complete guide to unified security platforms.
A unified security platform evaluation is a structured procurement process for assessing whether a physical security platform — combining video management, access control, and event automation on a single architecture — delivers the integration depth, licensing economics, and operational resilience it claims. A rigorous evaluation tests architecture under adverse conditions, not features in a controlled environment.
A unified security platform evaluation is a structured procurement process for assessing whether a physical security platform delivers the integration depth, licensing economics, and operational resilience it claims — tested under adverse conditions, not features in a controlled environment.
The standard RFP process tests features. The framework below tests architecture. The difference determines whether what you buy performs the way you were shown — or the way the vendor's environment was configured.
The most common and costly mistake in a unified security platform evaluation is running the selection process before auditing existing infrastructure. The hardware compatibility assessment should be completed before issuing the RFP — not after selecting a vendor.
Camera estate. Document every camera model currently deployed. Cross-reference against the ONVIF conformant products database to establish which units are compatible without replacement. An open platform accommodates ONVIF-compliant cameras from any manufacturer. A platform that specifies proprietary cameras is specifying a capital replacement programme — whether or not that appears in the initial quote.
Access control hardware. Identify controller models currently in place. Controllers represent the intelligence layer of an access control deployment, but the downstream hardware — reader interfaces, IO boards, door hardware, and cabling — represents as much as 90% of total access control deployment cost. A controller-only migration path that preserves all downstream hardware changes the financial classification of the project from a major capital replacement to a targeted controller refresh. Document how much of your existing access control estate is preservable before the first vendor conversation begins.
Servers and storage. Identify current recording and storage infrastructure. Assess compatibility with candidate platforms before the evaluation, not during it.
The output of this audit is a single figure: the percentage of existing estate that migrates without replacement. This is the hardware preservation credit in the business case — and it should be calculated before any vendor is shortlisted.
Most physical security RFPs assess features, certifications, and price. The five criteria below assess architecture. Each one reveals something a feature list cannot.
The Physical Security TCO Stack provides the calculation methodology for the licensing and hardware cost dimensions. The Five-Number CFO Brief structures these figures for a finance committee presentation once the evaluation is complete.
Standard vendor demonstrations test platforms under ideal conditions. The Platform Proof Stack is a set of five structured tests that must be run during any unified security platform evaluation — each designed to reveal architectural reality rather than a configured demonstration environment.
Test 1 — The WAN disconnection test. During the demonstration, physically disconnect WAN connectivity. Record: Do access control decisions continue at the door? Does video recording continue at the server? What does the audit trail show when connectivity restores — are events timestamped accurately, or are there gaps? A platform that processes access decisions at the edge continues operating without interruption. A platform that routes decisions through a cloud service does not. The WAN disconnection test is the single most informative test in the Platform Proof Stack. A vendor that declines to run it is declining to show you something.
Test 2 — The licensing scale test. Before the demonstration, request a 5-year cost model at 2× your current operator count. In a per-operator licensing model, this cost grows proportionally with headcount. In a per-device model with unlimited operators, it does not change. The compounded delta between these two models over five years is typically the most significant financial variable in the evaluation — and one that does not appear in a Year 1 quote. Ask every vendor on the shortlist to present this model. The vendors that resist the question are revealing something about the answer.
Test 3 — The integration dependency test. Request a live demonstration of a cross-system event: an access control credential attempt triggering a video clip, flagging an identity, and generating an alarm response — with no manual operator step between them. In a natively unified platform, this sequence runs on a shared event bus. In a middleware-dependent integration, it runs through an integration layer that must be separately maintained and requalified after every firmware update. Ask the vendor to show you the integration architecture diagram, not just the demonstration output.
Test 4 — The hardware compatibility test. Provide the vendor with your hardware audit output before the demonstration. Ask them to confirm in writing which specific camera models and controller types in your estate are compatible without replacement. Any claim of "broad ONVIF compatibility" that cannot be confirmed against your specific asset list should be treated as unverified until it is.
Test 5 — The exit cost test. Ask what it costs to leave the platform. Specifically: Can video recordings be exported in a standard, non-proprietary format? Can cameras be reused with a different VMS if you change platform? Are access control readers and door hardware portable, or proprietary? The vendor's answer reveals the lock-in architecture of the platform before you are locked into it.
Does your current evaluation script include the WAN disconnection test, a 5-year licensing model at 2× team size, and a confirmed hardware compatibility list against your specific estate?
Six specific patterns in vendor RFP responses indicate architectural risk. None are automatically disqualifying — each warrants a direct follow-up question before shortlisting.
"Full integration with 200+ platforms." Integration breadth is a middleware claim, not a unified architecture claim. Ask specifically: is the integration between VMS and access control native — on a shared event bus — or API-dependent via a middleware layer? The answer determines ongoing integration maintenance cost.
Per-operator pricing without a scaling model. If a vendor presents Year 1 pricing without a 5-year model at 2× current team size, request it explicitly before shortlisting. The absence of this model in an initial response is not an oversight.
Windows-based operating system. Windows VMS platforms carry a materially larger attack surface than hardened, purpose-built Linux alternatives — a gap visible in the volume of OS-level vulnerabilities catalogued each year in the NIST National Vulnerability Database. For environments with elevated cybersecurity requirements — critical infrastructure, government, healthcare — this warrants explicit risk assessment in the evaluation.
Proprietary hardware requirements. A platform that specifies its own cameras, controllers, or storage hardware as required components is building lock-in into the architecture. Confirm ONVIF compliance and open hardware compatibility before shortlisting, not after.
No sector-specific reference available. A vendor that cannot provide a reference from an organisation of comparable scale and sector should be treated as unproven in that context — regardless of total customer count or headline case studies.
Refusal to run the WAN disconnection test. The most informative red flag in the list — see Test 1 in the Platform Proof Stack. Treat any refusal to demonstrate with WAN physically removed as a disqualifying answer, not a scheduling inconvenience.
Every shortlisted vendor should provide at least one reference from an organisation of comparable scale and sector. A reference call that follows a script of questions provided by the vendor produces limited evidence. Run reference calls with your own questions.
Four questions that consistently produce useful evidence:
The answer to the fourth question is consistently the most revealing.
A structured unified security platform evaluation — hardware audit before the RFP, five architectural criteria in the framework, the Platform Proof Stack run in every demonstration, and reference calls with your own questions — produces a shortlist based on what platforms do under operational conditions rather than what they claim in a controlled environment.
Before confirming any vendor on your shortlist, put this question to every platform under consideration:
"If you disconnected the WAN in this room right now, would your platform continue to make access control decisions, and what would the audit trail look like when the connection came back?"
WaveFusion is designed to pass all five tests in the Platform Proof Stack. Access control decisions execute at the edge, independent of WAN connectivity. Sensor-based licensing — one licence per camera, one per reader, unlimited operators — means the 5-year model at 2× team size is identical to the Year 1 model. Hardware compatibility is confirmed against your specific estate before the evaluation begins. And the exit cost test has a straightforward answer: ONVIF-compliant cameras and standard access control hardware are reusable with any compatible platform.
If you are preparing a unified security platform evaluation and would like to run the Platform Proof Stack in a live demonstration, Wavestore's technical team can run all five tests in your environment.
Book a demonstration with Wavestore's technical team
Solutions for a world we can't yet see. Discover v6.48 features helping people and businesses.
