Server 2016 leaves support on 12 January 2027, and a good share of the video and access control hosts I see are still on it. The natural move is straight to Server 2025, and the 2016 to 2022 hardening guides on this site still apply almost entirely. What they do not cover is the handful of defaults that changed in 2025, several of which are things those guides told you to turn on by hand. On a general-purpose server that is good news. On a server running a VMS that talks to a ten-year-old NAS over SMB, it is an outage on the first reboot.
This page is the delta. Read the older guides for the baseline; read this for what 2025 does differently and what to check before you move a security system onto it.
The changes that matter, in one table
| Change | 2022 behaviour | 2025 behaviour | Risk to security systems |
|---|---|---|---|
| SMB signing | Required on domain controllers only; optional elsewhere | Required by default on all SMB connections, client and server | High. Archive storage on SMB, older NAS, and some appliances refuse or degrade. |
| NTLM over SMB | Allowed | Client can block NTLM to remote SMB servers; auditing on by default, blocking available by policy | Medium. Non-domain storage targets and workgroup appliances authenticate with NTLM. |
| Credential Guard | Off unless enabled | On by default on new installs that meet the hardware requirements | Medium. Some integrations that store or replay credentials in ways Credential Guard blocks. |
| LAPS | Separate download, legacy schema | Windows LAPS built in, with Entra and AD support | Low. Positive change; needs the schema extension. |
| Service accounts | gMSA | gMSA plus delegated managed service accounts (dMSA) | Low. Opportunity, not a risk. |
| TLS | TLS 1.3 available | TLS 1.3 preferred; TLS 1.0 and 1.1 disabled by default | Medium. Older cameras, panels, and SDK integrations that only speak 1.0 or 1.1. |
| Hotpatching | Azure only | Available on-premises through Azure Arc, subscription required | Low. Useful for hosts that cannot take a monthly reboot. |
| SMB over QUIC | Azure Edition only | Standard and Datacenter | Low. Not something a video host should be exposing. |
SMB signing, required everywhere
Every hardening guide for the last decade has said to require SMB signing. Almost nobody did it on member servers because it costs CPU and because something always broke. Server 2025 requires it by default, on outbound connections from the SMB client and on inbound connections to the SMB server, and the things that always broke now break on day one.
On a security system, the SMB connections that matter are archive storage and export shares. An Archiver writing to an SMB share on a NAS that does not support signing, or supports it badly, will either fail to connect or write at a fraction of its previous throughput. Some older NAS firmware negotiates signing and then performs so poorly under it that the Archiver falls behind and records gaps. The fix is to update the NAS firmware, move the storage to iSCSI, or as a last resort relax the signing requirement for that host through policy while you plan one of the first two. The storage design article covers why iSCSI is the better answer anyway.
Check before the move, not after:
# On the 2022 host today: does the storage target support signing?
Get-SmbConnection | Select-Object ServerName, ShareName, Signed, Dialect
# On a 2025 host: what the client will insist on
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
A Dialect below 3.0 on any connection is a target that will need attention regardless, because SMB1 is not installed on 2025 and SMB2 without signing is exactly what the default now refuses.
NTLM blocking
Server 2025 continues the NTLM deprecation that started in 2024. The SMB client can now be configured to refuse NTLM authentication to remote servers, and while the default is audit rather than block, the CIS and STIG baselines that will follow are going to recommend blocking, and a security team that applies them will do so.
What authenticates with NTLM on a security network: any storage target in a workgroup, any appliance that presents SMB but is not domain-joined, any camera or panel that pulls firmware or configuration from a share, and older SDK integrations that connect with a username and password rather than Kerberos. Domain-joined hosts talking to domain-joined hosts with proper SPNs use Kerberos and are unaffected.
Run the audit for a month before blocking. The audit events tell you exactly which connections would fail:
# Events for NTLM use by the SMB client (Server 2025)
Get-WinEvent -LogName "Microsoft-Windows-SMBClient/Audit" -MaxEvents 200 |
Where-Object Id -in 31017, 31018 |
Select-Object TimeCreated, Message
Every distinct target in that list is a decision: join it to the domain, give it a service principal name so Kerberos works, replace it, or exempt it explicitly and document why.
Credential Guard on by default
Credential Guard isolates domain credentials in a virtualisation-based container so that a compromised kernel cannot read them. On a fresh 2025 install on hardware with UEFI, Secure Boot, and a TPM, it is now on. That is correct, and it should stay on.
What it breaks: anything that depends on credential delegation mechanisms Credential Guard disables, most visibly unconstrained Kerberos delegation and older NTLMv1 flows. Security system integrations occasionally lean on these, particularly the ones that were written to make single sign-on work between a VMS and a directory and never updated. The symptom is an integration that authenticated fine on the old host and fails with an access denied on the new one, with nothing else changed.
Test the integrations on a 2025 host in the lab with Credential Guard on before the production move. If one fails, the vendor’s current SDK almost always has a fix; the wrong answer is to turn Credential Guard off on the production host to accommodate an old plugin.
Windows LAPS, built in
The baseline guides told you to deploy LAPS for the local administrator password. On 2025 it is part of the operating system, it supports both Active Directory and Entra, and it can manage the DSRM password on domain controllers. Extend the schema, set the policy, and the shared local administrator password that every video server on the site had in common stops being a problem.
Two things to get right on security hosts. First, the account LAPS manages should be the built-in administrator, renamed, and there should be no other local administrator accounts, including the one the integrator created at commissioning. Second, the password rotation should not be so aggressive that it rotates during a maintenance window someone is in the middle of. Thirty days is fine.
Delegated managed service accounts
Group managed service accounts have been the right way to run a service without a password since Server 2012, and most VMS and access control services are still running as a named domain user with a password that expires in ninety days and takes the service down when it does. Server 2025 adds delegated managed service accounts, which can be linked to an existing service account and take over its permissions, which makes the migration from a password-bearing account much less disruptive.
Whether the platform supports it is the question. Genetec, Milestone, and most access control servers will run their services as a gMSA, and the vendor documentation for each says how. The dMSA path is the same from the platform’s point of view. Plan the service account migration as part of the host move, because it is far easier to do on a fresh install than to retrofit.
TLS 1.0 and 1.1 gone by default
Server 2025 disables TLS 1.0 and 1.1 out of the box. The baseline guides told you to do this by registry on 2016 through 2022, and on the systems where it was done, the things that broke are known. On the systems where it was not, the move to 2025 is where they break.
The usual suspects: cameras on old firmware whose HTTPS only offers 1.0, access control panels with embedded web servers from the previous decade, and SDK integrations compiled against an old .NET framework that never enabled 1.2. The camera and panel problem is a firmware update or a replacement. The SDK problem is a vendor conversation. Neither is a reason to re-enable TLS 1.0 on a host that holds video evidence.
The TLS section of the getting-started guide has the registry keys and the .NET strong-crypto settings that apply unchanged on 2025.
Is the platform supported on it yet
None of this matters if the VMS or access control vendor has not qualified Server 2025 for the release you run. Check the vendor’s supported platform matrix for your exact release before planning the move, and plan for the possibility that the answer is “supported from the next release,” which turns an OS move into a platform upgrade with an OS move underneath it. For Genetec, the migration paths page covers the version rules that decide what order the two moves have to happen in.
Pre-move checklist
- Vendor platform matrix confirms 2025 for the release in production.
- Every SMB target inventoried with its dialect and signing support. Archive storage on SMB has a plan: firmware, iSCSI, or a documented exemption.
- NTLM audit run for a month on the existing host; every target on the list has a decision.
- Integrations tested on a 2025 lab host with Credential Guard on.
- Cameras, panels, and SDK integrations checked for TLS 1.2 support.
- LAPS schema extended; policy ready; commissioning accounts removed.
- Service accounts moving to gMSA or dMSA as part of the build.
- The rest of the baseline guide applied, because 2025 changed defaults, not the need for a baseline.
The short version: Server 2025 turns on several things you were supposed to have turned on already. If you did, the move is uneventful. If you did not, the move is where you find out what was depending on them being off.