How to modernise multi-site distribution centre security without taking a ramp offline

Brownfield security modernisation is the upgrade of security on sites that already operate, carried out in phases so that gates and ramps stay in service. Done well, it gives you a documented baseline in weeks and a central audit trail in months, so you can demonstrate control long before the last site is finished.

Key Takeaways

A phased route keeps gates and ramps in service, and the right test for a programme is how early it starts producing evidence, not how fast it finishes.
The programme runs in five phases: Analysis, Minimum, Standard, Premium and Optimisation. The durations given are planning assumptions to test at a pilot site, not benchmarks.
A Minimum deployment gives visibility and evidence, not automated control, so ask any supplier what you will have if the programme stops after the first tier.
Decide who may change the operating mode, on what trigger, and make sure the audit trail survives a network outage.
Before you buy, check four conditions: adequate master data, separate IT and OT networks, tolerance decisions taken at management level and an incident response process that works in practice.

Is full replacement or delay the only choice for a live distribution centre?

No. Both options carry a risk that is easy to underestimate, and a phased route avoids most of each.

Replacing everything at once concentrates risk in the cutover. Sound migration practice treats downtime, sequencing and cutover order as the main risks to manage. It moves one system at a time rather than rebuilding a site in one step, and it runs old and new systems in parallel at a pilot site before anything is switched off.

Delay carries its own risk. An estate left alone keeps its current controllers, credentials, firmware and audit capability. These may no longer meet the evidence standard your business now needs. Ageing controllers and unsupported firmware are an availability risk too: a failed controller without spare parts or vendor patches stops a door as surely as a project does. Access-control maintenance guidance also points to legacy encryption and missing audit trails as weaknesses that reach beyond a single door.

Why is the order of a modernisation programme more important than its speed?

Because the question that now carries liability is not how fast the programme finishes. It is how early it starts producing evidence.

Modernisation is usually framed as a trade-off between capital, risk and downtime. Inside that frame the answer is always “it depends on budget”. A different frame fits today’s environment better. Exposure has two parts: the state of your estate, and your ability to demonstrate control of it.

Consider what you are asked to show. After an incident, an insurer or a shipper wants to know who was admitted, on whose authority and what was overridden. Ahead of a TAPA FSR renewal, an auditor wants documented evidence. TAPA FSR certificates are valid for three years, require annual internal self-audits, require gaps to be closed within 60 days, and should be renewed at least three months before expiry to avoid a lapse. If you are certified, having a control is only the starting point. You also have to show that the control operated, was monitored and was corrected when it failed.

Measured that way, a phased programme is in a better position long before the last site is finished. It reaches a documented baseline in a few weeks and a central, tamper-resistant audit trail within months. A full replacement produces nothing until it completes. The phased route is not the compromise chosen because the fast option is unaffordable. On the measure that matters, it is the better option.

The ramp is the clearest test of this, because custody of someone else’s goods changes hands there. Why the loading dock carries the exposure it does [link pending] is covered in a companion article.

Measure	Full replacement	Do nothing	Phased migration
Ramp and gate availability during rollout	At risk during site-wide cutover; mitigated only by parallel systems and careful sequencing	Also at risk: unsupported firmware, ageing controllers and absent audit trails reduce resilience	Existing systems remain in service; cutover occurs by zone, system or site wave
Capital commitment	Concentrated up front	Low now, but deferred failure, retrofit and incident costs	Staged by phase and site
First demonstrable control	Usually at completion	Only after a manual baseline is produced	Baseline after Phase 0; central audit trail after Phase 1
Multi-site scalability	Each site may need a fresh build	Each site stays locally configured and inconsistent	One template, piloted once, then adapted locally

Qualitative comparison based on common migration practice. It is not a like-for-like benchmark of published deployment outcomes.

Which regulations make evidence matter, and who do they apply to?

Two EU instruments frame the question, and they address different things. NIS2 sets cyber and supply chain security duties for in-scope entities. The CER Directive (2022/2557) addresses the physical resilience of critical entities, including transport.

National positions differ, and they are still moving:

Belgium: the NIS2 law was adopted on 26 April 2024 and entered into force on 18 October 2024, one day after the EU deadline of 17 October 2024.

Germany: the NIS2 implementation act entered into force on 6 December 2025, with no transition period. The KRITIS-Dachgesetz, which implements the CER Directive, entered into force on 17 March 2026.

France, the Netherlands and Spain: had not notified full transposition of NIS2, and on 8 July 2026 the Commission referred them to the Court of Justice for that failure. Check the current position before relying on any national date.

Scope is per operator, and it is narrower than many assume. Under the KRITIS-Dachgesetz, a critical facility is one that is essential for a critical service, and the standard threshold is a facility supplying 500,000 residents. The German Interior Ministry estimates that about 1,700 facilities must meet all the resilience requirements. Transport and traffic is a covered sector, but that does not make every distribution centre a critical facility. NIS2 scope depends on sector, size and headcount. Assess it for your own entity, and keep both outcomes open until you have.

What does brownfield security modernisation look like, phase by phase?

It runs in five phases. Each adds capability to your operating estate and gives you something new to show. The durations below are indicative planning figures for a typical multi-site programme, not an industry benchmark. Actual timing depends on site count, system age, data quality, network readiness, works council requirements and the extent of local customisation.

A useful way to stage the work is to treat the capability tiers as the phases themselves. Minimum, Standard and Premium are what Phases 1, 2 and 3 activate. They do not run as a separate track. Start at Minimum but design the architecture against a Premium target. If the platform is the same at every tier and only the activated modules grow, a later upgrade needs no re-implementation. Ask any supplier to confirm that this holds for their design.

Phase 0, Analysis: 4 to 6 weeks

This phase covers inventory, zone plan, system inventory, risk analysis and interface analysis. It comes first because every later decision should rest on a documented baseline and not on an assumption. Afterwards you can show what exists, where it sits and where the interfaces are. That is already more than many estates can produce.

Phase 1, Minimum: 3 to 6 months

This phase connects the security management platform, access control, the gate and existing CCTV. It comes next because the central platform and audit trail are what everything else reports into. Open interfaces make this possible without replacing everything: SIA OSDP v2.2.2 for access control devices, ONVIF profiles for video (Profiles S and T) and for access control (Profiles A, C, D and M), and REST APIs. Interoperability reduces replacement scope, but it does not remove configuration, firmware, credential or integration work. Afterwards you can show a tamper-resistant record of what happened at critical entrances.

Phase 2, Standard: a further 4 to 6 months

This phase adds a risk-based decision engine, yard management, automated degraded mode, a KPI framework and the cyber-physical basis. A risk-based decision engine weighs each check by confidence instead of passing or failing it outright. It follows Phase 1 because it needs the platform beneath it. Afterwards you can show why each decision was taken and what the fallback was.

Phase 3, Premium: a further 6 to 12 months

This phase brings zero trust network access, behaviour analytics for insider threat, multi-site management and advanced compliance. It follows because that work assumes a stable operational layer. Afterwards you can show one consistent record across sites.

Phase 4, Optimisation: ongoing

This phase is calibration of the decision engine, KPI review, red team testing and audit preparation. It is last and continuous because calibration needs live operating data, which only a working deployment produces. Afterwards you can show controls that have been tested, not only installed.

What counts as minimum viable evidence?

Define what control means in month one, so that the first phases can be judged against it:

A complete asset and zone inventory.
A documented risk ranking for entrances, yards and ramps.
A central event record for access decisions at critical doors.
A retained audit trail for system and user changes.
A named owner for each operating mode and escalation path.
A tested process for preserving evidence after an incident.

What does a Minimum deployment leave out?

It leaves out automated decision-making and automated fallback, and you should plan on that basis. A sensible first tier gives you a central situation picture, access control at critical entrances, licence plate recognition at the main gate, existing cameras brought into one view and a tamper-resistant central audit trail. A risk-based decision engine, orchestration, yard optimisation and automated degraded mode arrive with the second tier.

At that point a business continuity manual should exist on paper, but the automated fallback behaviour will not. Stopping there gives you visibility and evidence, not automated control. This is the question that rarely gets a direct answer in phased proposals, so put it to any supplier you short-list: what exactly will I have if the programme stops after the first tier?

What happens to access decisions when the network drops?

They continue at the edge, but the useful question for any phased programme is one of governance: who may change the operating mode, on what trigger, and does the audit trail survive the outage? Whether the controllers have a local cache is the lesser question.

Define four operating modes: Normal, Degraded, Reduced Service and Lockdown. Each should have documented triggers, defined procedures and confirmed sign-off. A workable pattern: the system proposes Degraded mode automatically after a loss of heartbeat from a core system, for example more than 30 seconds, and the shift supervisor confirms it. Moving from Degraded to Reduced Service is a named decision taken by the safety manager. It is triggered by a second core system failing or by local data ageing beyond a set limit. Lockdown rests with the safety manager or management. Every transition is logged. The 30 seconds is an example to tune to your network, not a published requirement.

Edge controllers should keep making access decisions from local data for as long as your worst realistic outage lasts. A figure such as 72 hours covers a long weekend with margin, and is a useful test to put to any supplier. Store decisions taken during an outage locally and synchronise them afterwards, so the audit trail covers the outage instead of stopping at it. This capability normally arrives with the second tier, not the first, which connects back to the previous section.

How does a security standard scale from one site to many?

By defining the standard once, proving it at one site, and then repeating it with local adjustments only. Define the standard as a configuration template, allowing one to two weeks. Validate it at a pilot site over four to eight weeks, choosing a site with average conditions, not your newest building and not your worst. Document what the pilot teaches and use it as the specification for every later site. If the template holds, each further location should then take one to three weeks, with adjustments only for local specifics and no fresh integration work. Treat these as planning assumptions to test at your pilot, not benchmarks.

For a brownfield estate, a sound approach is to connect the central platform first and replace hardware gradually. Pilot in one area before rolling out per location. The advantage is investment protection and no shutdown of operations. The risk is interface complexity and the management of the migration phases. Tracking a few measures lets you see that risk early:

Percentage of sites with a completed Phase 0 baseline.
Percentage of critical entrances reporting into the central platform.
Percentage of access events with complete identity, time, location and decision outcome.
Mean time to detect a controller, camera or reader failure.
Percentage of degraded-mode transitions that are logged and supervisor-approved.
Percentage of audit findings closed within 60 days, which matches the TAPA corrective-action expectation.
Number of sites on the standard configuration template compared with sites running local exceptions.

These are measures to define and track, not benchmarks to quote. Set your own targets from your baseline.

What has to be true before you buy anything?

A brownfield programme fails when it treats migration as a hardware project. The critical artefacts are the baseline, the role model, the tolerance decisions, the fallback rules and the evidence that each was approved. Four conditions have to be established before you procure from anyone:

Master data is adequate.
IT and OT networks are separate.
Decisions on tolerances and the role model are taken at management level.
An incident response process works in practice.

A phased programme needs these in place. A risk-based decision engine is only as good as its governance. Without named policy owners, an audit process and regular calibration, it will either act without control or block operations.

A simple readiness check turns the four conditions into a diagnostic. Score each site 0 to 2 on each of six areas:

Area	What to look at
Master data	Sites, zones, doors, readers, cameras, vehicles, carriers
Network segregation	IT and OT separation, VLANs, firewall rules, remote access
Identity governance	Named policy owners, role model, approval workflow
Incident response	Tested escalation, evidence preservation, recovery owners
Legacy exposure	Unsupported firmware, local databases, proprietary integrations
Evidence capability	Audit logs, CCTV retention, seal records, exception records

Sites that score low on master data or network segregation should be fixed before any platform is connected, because the platform will inherit every gap.

Conclusion: where should you start?

Brownfield security modernisation works when each phase earns its place by letting you show something new. Start with Phase 0, which needs no product decision. A documented baseline is useful whichever route you take, and it tells you which sites are ready and which need preparation first. Then agree the minimum viable evidence list above with security, operations and IT, so the first phase is judged on what it lets you show.

You can work through this sequencing with Primion’s logistics team. See how operators apply brownfield security modernisation across their own sites in logistics and distribution security.

See how operators approach loading dock security across their own sites

Discover our solutions

Frequently asked questions

What is brownfield security modernisation?

Brownfield security modernisation is the upgrade of security on sites that already operate, carried out in phases so that gates and ramps stay in service. Each phase adds capability to the live estate and gives you something new to show, from a documented baseline to a central audit trail.

Why does the order of the phases matter?

Each phase builds on the one before it. The central platform and audit trail must exist before a risk-based decision engine can use them, and calibration needs live operating data from a working deployment. The order also decides how early you can show evidence of control.

What does a Minimum deployment give you?

A central situation picture, access control at critical entrances, licence plate recognition at the main gate, existing cameras in one view and a tamper-resistant central audit trail. It does not include a risk-based decision engine, yard optimisation or automated degraded mode, so it delivers visibility and evidence, not automated control.

How does a phased programme scale across several sites?

Define the standard once as a configuration template, validate it at a pilot site with average conditions, then apply it to each further site with local adjustments only. The durations in this article are planning assumptions to test at your pilot, not published benchmarks.