Every network has one: a NAS from another era, a camera system, a machine controller that speaks only old NTLM and cannot be patched. It needs access - and the rest of your network needs it contained. Both are possible at the same time.
The worst response to a legacy device is also the most common: somebody lowers the authentication level on a server, or on the whole domain, 'just so the NAS works again'. Now every machine trusts a little less, forever, because of one box. The professional pattern is the opposite: keep the network hardened, and build a small, watched enclosure around the device that cannot change. Here is that pattern, step by step - it costs an afternoon once, instead of security every day.
Three small, deliberate allowances for one device - versus one global weakening for all devices.
Create a dedicated account used by this device and nothing else. Give it exactly the access it needs - read/write to its one folder, nothing more, no administrator rights anywhere. If the device is ever compromised or starts misbehaving, that account's footprint is tiny, and you can disable the account to cut the device off without touching anyone's real login.
On even a modest managed switch or business router you can usually place the device on its own VLAN or subnet, with rules that allow it to reach only the one server and share it genuinely needs - and nothing else on the network. An attacker who lands on that box finds a dead end instead of a master key. If your hardware cannot do VLANs, a simple second subnet behind the server still beats a flat network where the oldest device can talk to everything.
Where NTLM must be permitted, permit it at the smallest possible scope. The domain policy Network security: Restrict NTLM: Add server exceptions in this domain exists exactly for this - it names the servers that may still receive NTLM while the rest of the domain denies it. Name the one server the device talks to. Do not lower the LAN Manager authentication level domain-wide, and do not set a global allow because it was quicker.
Isolation is a containment strategy, not a pardon. Record the device, its weakness, the exception you made and a review or replacement date in the same document. When the device is replaced - and devices always get replaced eventually - the exception gets removed in the same job. Exceptions without dates are how 'temporary' NTLMv1 support quietly survives for a decade.
The full process with live demonstration - every setting shown on screen, step by step.
Watch Full VideoNo - that weakens every connection to that server, and usually the setting spreads further than intended. Isolate instead: a dedicated low-rights account for the NAS, network rules so it reaches only what it needs, and an exception scoped to that one server, with a replacement date recorded.
You still have options: a separate physical network or second subnet for the device, firewall rules on the server itself limiting which addresses may reach the share, and the account-level restrictions. Layered small controls still beat one big weakening.
It is a deliberate, named, reviewable allowance for specific servers - the opposite of a blanket setting nobody remembers making. The difference is scope and documentation: one server, one reason, one review date.