The router is shipped to site, connected to power and a circuit by anyone, and configures itself from the controller - with the identity check being the part that matters.

On first boot the device reaches a manufacturer or customer service using a certificate installed at the factory, authenticates, and is told which controller it belongs to. It then downloads its configuration, joins the overlay and comes into service.

The practical requirement is that its first circuit gives it a working internet path with an address, usually by DHCP. Sites with static addressing or a captive portal need a manual step.

The security of the process rests on the certificate and on the device being registered to the correct organisation before it ships, which is why the serial numbers matter and why devices bought through unofficial channels can be difficult to onboard.

When it works, a branch is brought up by someone with no network knowledge in a few minutes, and a failed router is replaced the same way. That is usually the largest single operational saving in the whole model.

By measuring each path continuously and matching what it measures against a policy for each application.

Probes run over every transport, measuring latency, jitter and loss several times a second. That gives a live view of each path's quality rather than just whether the link is up - which is important, because a circuit that is up and losing five per cent of packets is worse than one that is down.

Policy defines what each class of traffic needs. Voice and video are steered onto the path meeting a jitter and loss threshold; interactive business applications get the low-latency path; backups and updates take whichever is cheapest.

When a path degrades past its threshold, affected traffic moves within a second, usually without dropping sessions because the tunnel endpoints stay the same.

Some implementations go further with forward error correction or duplicating critical packets across two paths, which trades bandwidth for resilience on links that are lossy rather than failing.

For most traffic yes, provided the design accounts for what broadband does not guarantee.

The tunnel provides the privacy that the private circuit used to, so confidentiality is not the issue. What a private circuit also provided was a service level: committed bandwidth, symmetric speeds, defined latency and a repair commitment.

Broadband gives none of those. It is usually asymmetric, contended at busy times, and repaired on a best-effort basis measured in days rather than hours.

The standard answer is two dissimilar broadband services, or one broadband plus cellular, with the router steering around whichever is misbehaving. Two unreliable paths, actively measured, deliver better real availability than one reliable-on-paper circuit - and cost less.

What still justifies a private circuit is a site whose traffic genuinely needs guaranteed capacity: a contact centre, a site running real-time clinical or industrial systems, or one hosting services others depend on.

Partly, and how far depends on the platform and on where the site's internet traffic is meant to go.

Most SD-WAN routers include stateful firewalling, and many include application recognition, URL filtering and intrusion prevention as licensed options. For a small branch that is often sufficient.

The design question is where internet-bound traffic exits. Backhauling it through the data centre means all inspection happens at one well-equipped point, at the cost of latency and head-end capacity. Breaking out locally is faster and cheaper but means each branch needs its own inspection - either on the router or by steering the traffic to a cloud security service, which is the common modern answer.

That combination - local breakout with cloud inspection - is why the two product categories have converged, and why the licensing should be examined carefully: the security features are frequently a separate subscription from the SD-WAN itself.

The routers keep forwarding with the policy they already hold - but nothing can be changed, and that limitation should be understood before it is discovered.

The control plane and data plane are separate. Tunnels stay up, path selection continues using the current policy, and traffic flows normally. A controller outage is not a network outage.

What stops is management: no configuration changes, no new sites onboarded, no policy updates, and usually no monitoring or reporting during the outage.

Some designs also route control traffic through the controller's cloud for certificate and key rotation, and prolonged unreachability can eventually affect tunnel re-establishment. Ask the specific question of the vendor: how long can the fabric run without the controller, and what fails first.

Where the controller is self-hosted, it needs the same resilience thinking as any other central system. Where it is a cloud service, the vendor's own availability record becomes part of the network's.

By shipping an identical model to site, having anyone plug it in, and letting it provision itself - which is the point of the model.

The configuration lives in the controller, not the device. A replacement claims the site's identity once it is registered, downloads the same policy and rejoins the overlay.

The practical requirements are that the replacement is registered to the organisation before it arrives, that somebody can reconnect the cables the same way, and that the site's first circuit still works - a router replacement does not help if the circuit is the fault.

Keeping a spare on the shelf at a regional site is common and sensible, particularly where courier times are long. The spare should be the same model and should be checked periodically rather than left in a box for three years.

Document the physical cabling with a photograph taken at installation. That single habit removes most of the errors in remote-hands replacements.

Below roughly ten sites the licensing often outweighs the benefit - but the threshold moves depending on how remote and how unstaffed the sites are.

The savings come from cheaper transport, central management and simple site turn-up. With three sites, transport savings are small, central management replaces very little manual work, and the subscription is a new recurring cost.

What shifts the calculation downward is remoteness and staffing. A handful of sites in different countries, with no technical staff and long travel times, benefit from zero-touch provisioning and central policy far more than a dozen sites in one city.

Dual-transport resilience also matters more for some businesses than others. A retail site that cannot take payments when the circuit fails values sub-second failover much more than an office where people can wait an hour.

Where it is not justified, an ordinary branch router with a cellular backup and a configuration template achieves much of the same for less.