One 802.1X port template must ship to closets on two switch vendors after an acquisition: what do you pin, and who pays?

## What a port template actually is A port template is the only artefact that scales an admission decision across hundreds of wiring closets, and its content is behavioural: 1. **Pre-authentication behaviour** - what crosses the port before a verdict (EAPOL only) and what a device that never answers gets. 2. **Host mode, per port class** - the least permissive mode that the devices on that class of port actually require. 3. **Timers** - how long the authenticator waits and retries, and the session lifetime including reauthentication and inactivity. 4. **Failure posture** - what the port does when authentication is refused, and who is allowed to change that in the field. Across two vendors, the syntax differs, the *defaults* differ, and the ordering of fallbacks differs. That last one bites: a template that says nothing about a behaviour is not neutral, it silently adopts each platform's default, and you now have two admission policies with one name. The reviewable artefact should therefore be a per-port-class behaviour table with two implementations, plus a test that asserts the behaviour on both. ## The acquisition is the hard part, and it is not technical Two years after an acquisition, the acquired closets have their own phone fleet, their own cabling, and their own operations team who did not choose your standard. Three organisational facts dominate: - **You do not know what can authenticate.** Enrolment state on the acquired endpoints is somebody else's history. Until it is inventoried, an enforcement date is a promise to cause outages. - **The phone fleet dictates the mode.** Daisy-chained PCs behind phones mean multi-domain on that port class, and multi-domain permanently gives up `exactly one authenticated device on this port`. That is an accepted risk, and acceptance needs a name attached. - **Somebody else owns the money and the downtime.** The people whose factory floor or trading desk goes quiet on cutover day are not on your team. They can refuse, and a plan that assumes they cannot is not a plan. ## The two positions you are choosing between **Position A - standardise on multi-domain and accept the exposure.** Cheap, fast, works on both vendors, keeps the phones. The residual is explicit: a device spliced onto an authenticated link, or one impersonating an authorized address, is not stopped by the port. You mitigate by shrinking what the port reaches, by aging out quiet sessions, and by physical control of the highest-value sockets. You write the residual down and get it signed. **Position B - fund per-frame protection on the access link.** MACsec keyed from the successful authentication makes the link itself trustworthy and turns a splice into an outage rather than a foothold. It requires capable switch hardware and capable endpoint supplicants, so in a mixed post-acquisition estate it is a refresh programme measured in capital and quarters, not a template change - and part-coverage means two templates and a decision about the uncovered half. A principal answer does not pretend B is free or that A is negligent. It says which port classes justify B (the ones where an attacker on the link reaches something that matters), puts A everywhere else with a written residual, and names the risk owner for each. ## How you sequence it without owning an unplanned outage - **Non-enforcing first, everywhere.** Run the full exchange, log the verdict, authorize regardless. This is the inventory, and it is also the argument: you can now show the acquired site's leadership exactly how many of their devices would have been refused. - **Closet by closet, with a named owner per cutover** and a defined rollback that is a template change, not an emergency `disable it all`. - **A permanent exception register**, owned and reviewed, because the exceptions are the design from the attacker's point of view. - **Assert the behaviour, do not trust the config.** A drifted closet running a permissive host mode is invisible until someone tests it, so periodic verification that the port denies is part of the programme, not an afterthought. ## The failure mode to avoid The classic one is announcing an enforcement date to demonstrate progress, hitting the acquired site's unenrolled endpoints, taking an outage, and being told to disable enforcement estate-wide. You then have the config, the licences, the operational burden and none of the control - a deployment that exists on paper. Sequencing behind the inventory, and letting the site owner accept a documented residual instead of a hard cutover, is what keeps the programme alive.