UniFi Health Check Advanced tier
Manhattan-area residence May 2026
Where the findings are
16 UniFi devices · 62 clients mapped
The big picture
Your network, in plain terms.
Your hardware is in great shape — a current-generation UDM-Pro gateway, two PoE switches, five WiFi 6 access points, and eight cameras, all online and on current firmware. The findings below are not about broken gear; they describe how the network is configured to handle remote access, Wi-Fi security, and how devices are grouped together.
One item deserves prompt attention: there are three openings on the public internet pointed at your Crestron control system. Crestron — the manufacturer — now tells installers to switch to a cloud relay for the homeowner’s phone app and a private VPN tunnel for setup tools, and to remove those openings afterward. Nothing here indicates an active incident, and there was no sign of unauthorized devices in the data reviewed.
Everything in this report is something you, your IT person, or your integrator can review and apply on your own schedule. Only settings were read — nothing was changed.
What we reviewed
A remote, read-only configuration review of the UniFi console across Wi-Fi, networks and VLANs, WAN, firewall and policy, port-forwarding, VPN, CyberSecure, admin/identity, and the full device and client inventory.
No configuration was changed, no passwords were requested, and no active scanning or penetration testing was performed. A few things can’t be confirmed from a read-only review and are flagged as questions rather than findings: each admin’s specific second-factor method (held privately at the Ubiquiti account level), the gateway’s configuration-backup cadence and remote-restore readiness, and whether any current integrator tool still depends on the existing port-forwards.
Findings
Grouped by severity — 12 in total.
Each finding carries a plain-English explanation, the technical observation and recommendation behind it, and — where it helps — the actual console setting as evidence. Severity is rated against this specific home, not a generic enterprise threat model.
Your Crestron automation system has three doors open to the internet
Your Crestron control system can be reached directly from the public internet through three separate openings — from anywhere in the world.
The manufacturer no longer recommends this. Crestron’s own current guidance is a secure cloud relay for your phone app and a private tunnel (a VPN) for your installer’s setup tools — and to remove these openings afterward.
Closing all three changes nothing about how you use the house day to day. The conversation to have with your integrator is collaborative: bring the system in line with Crestron’s current guidance and retire the inbound openings.
Crestron port-forwards reachable from any source IP
Observation
Three port-forward rules on the UDM-Pro expose the Crestron CP4-R at 192.168.88.20 to the public internet — external 8443 → internal 443 (HTTPS), 50001 → 50001 (Crestron Home App), and 41796 → 41796 (Secure CIP). The From field on all three is Any (any source IP is permitted) and Protocol is TCP/UDP. Crestron’s current documentation states remote app access “has been replaced with a secure, cloud-based remote access service” and that “port mapping is not required.”
Recommendation
Retire all three, per Crestron’s guidance: move the homeowner’s mobile app to Crestron’s cloud relay (removes the 50001 rule) and provide integrator access to the processor through a UniFi WireGuard VPN (F-02) (removes 8443 and 41796). Crestron directs installers to “set up a secure VPN connection” and, afterward, to “remove port mapping from the router.” Interim, while the VPN is stood up: tighten each rule’s From field from Any to the integrator’s known public IPs and set Protocol to TCP. Every major AV-control vendor has converged on this model — Lutron, Control4 (4Sight / Control4 Connect), and Savant all use an outbound cloud relay with no inbound port-forwarding required.
There’s no private tunnel (VPN) for remote access yet
There’s no private, encrypted tunnel — a VPN — into your home network. A VPN is the modern, safe way for your installer to reach equipment remotely without leaving anything open to the public internet.
Because there’s no tunnel, every remote-access need has turned into another open door on the internet — which is exactly what created the Crestron exposure above.
Stand up a VPN so remote access runs through one private tunnel, then retire the open doors it replaces.
No LAN remote-access VPN configured
Observation
Settings → VPN shows no VPN Server, VPN Client, or Site-to-Site VPN configured. (UniFi cloud access to the controller itself is independent of this; the gap is specifically that there is no VPN tunnel into the LAN.) This is the direct cause of F-01’s exposure and blocks any clean path to retiring the open Crestron rules.
Recommendation
Stand up a UniFi VPN server. WireGuard is the recommended choice on the UDM-Pro — modern, fast, and supported by macOS / Windows / iOS / Android clients. Once verified end-to-end (the integrator’s technician reaches the Crestron processor through the tunnel), proceed with retiring the port-forwards in F-01. Crestron’s own guidance names a VPN as the substitute for installer configuration access.
Sources1
One camera still uses its factory password
One of your cameras — the driveway-facing bullet camera — is still using the password it shipped with from the factory. The other seven cameras have unique, managed passwords.
Factory passwords are public knowledge and are the first thing automated attacks try.
Rotate it — a two-minute fix — so the camera stops using its factory default.
One UniFi Protect camera retains a default administrative password
Observation
One G4 Bullet (driveway-facing) is adopted and reachable on the management network, but the controller flags it with a Default Password In Use advisory. The other seven cameras have rotated passwords managed through Protect. Although not directly internet-exposed today, the flat LAN (F-05) means any LAN device that fell to an attacker could attempt to reach it.
Recommendation
Rotate the camera password from the Protect application’s device-management screen and confirm the Default Password In Use advisory clears.
Your Wi-Fi uses older encryption than your equipment supports
All five of your Wi-Fi networks use the older WPA2 encryption mode. The newer WPA3 is supported by virtually all current phones, laptops, and tablets — and by every access point you already own.
WPA2 without the newer protections leaves the door open to a nuisance attack that can knock devices off the Wi-Fi.
A mixed WPA2/WPA3 mode lets older devices keep working while newer ones get the stronger encryption; turning on “Protected Management Frames” blocks that nuisance attack.
All Wi-Fi SSIDs are WPA2-only with Protected Management Frames disabled
Observation
All five SSIDs are set to Security Protocol = WPA2, with Protected Management Frames (PMF) = Disabled. WPA2 without PMF is susceptible to deauthentication and beacon-spoofing that can knock clients offline or push them onto a malicious AP. PMF is defined in IEEE 802.11w and is standard on modern clients; all five APs are WiFi 6 (U6-Pro / U6-LR) and support WPA2/WPA3 transition mode and PMF natively.
Recommendation
Move each SSID to WPA2/WPA3 transition mode with PMF = Optional. Test one SSID first — the IoT SSID is the lowest-risk starting point, since IoT clients are the most likely to surface any compatibility issue quickly.
Sources10
Everything is on one big network
Right now your phones, computers, IP intercoms, Crestron and Lutron processors, cameras, Sonos, and printer all share one network — the same digital street.
If any single device is taken over — say, an older smart-home gadget — it can reach everything else directly.
Give each type of device its own lane (a VLAN), with rules that stop the smart-home and camera lanes from reaching your personal devices.
Flat LAN — no VLAN segmentation between personal, IoT, intercom, automation, and camera devices
Observation
Only one logical network exists: Default on 192.168.88.0/24. The 62 clients — personal computers and phones, the Crestron Home processor, the Lutron HomeWorks processor, 2N IP intercoms, Sonos, UniFi Protect cameras, and a printer — all share one broadcast domain. IoT and automation devices frequently ship with weak or hard-coded credentials; cameras and access-control intercoms belong on isolated management networks.
Recommendation
Introduce at least four logical networks: Trusted personal (laptops, phones, tablets); Home automation (Crestron, Lutron, intercoms — allowed to reach the internet and their named cloud endpoints, but not to initiate into Trusted); IoT / smart-home (Sonos, lighting accessories, printer); and Camera management (Protect NVR + cameras, locked to that VLAN, outbound to Ubiquiti cloud only). Enable multicast / mDNS reflection selectively where AirPlay / Chromecast / Sonos discovery must cross zones.
Your installer holds the top account, and one login is shared
Five people can log in to manage this network. Ubiquiti now enforces two-factor authentication on the cloud accounts used to reach this console, so the baseline protection is in place.
Two things are worth deciding deliberately: the top-level “Owner” account belongs to your AV integrator (common in many homes, but it means control sits outside the household if you ever change installers), and one integrator login looks like a shared account used by several technicians. A shared login makes it impossible to tell who did what, and harder to remove access cleanly when staff change.
Decide whether console Ownership stays with the integrator or transfers to a household account, replace the shared login with per-person technician accounts under least-privilege roles, and confirm each admin has a strong second factor enrolled.
Console Owner sits with the AV integrator; one integrator account is a shared service account
Observation
The console Owner role is held by an integrator mailbox of the form service@<integrator>.example — a role-named mailbox, suggesting a shared service account used by multiple technicians. Two further integrator accounts hold Custom roles tied to named individuals; two homeowner accounts hold Super Admin. Owner-on-integrator is common in professionally installed AV and is not itself a problem, but a shared account defeats MFA enforcement, offboarding, and audit attribution.
Recommendation
Decide deliberately whether console Ownership stays with the integrator or transfers to a homeowner-controlled account — there is no single right answer, but make the decision. Replace the shared service account with per-individual technician accounts under least-privilege Custom roles so MFA and offboarding can actually be enforced. Independently, confirm each admin has enrolled a strong second factor on their Ubiquiti account — an authenticator app or a passkey rather than email one-time codes.
A feature that lets devices open their own internet doors is switched on
A convenience feature called UPnP is turned on. It lets devices inside your home open their own openings to the internet automatically, without anyone reviewing them.
On a network that already has openings pointed at the Crestron system, this quietly widens the surface in ways you can’t easily see.
Turning it off is the safer default; anything that genuinely needs an opening can be set up deliberately.
UPnP is enabled on the WAN interface
Observation
Internet → WAN → UPnP is On, and the rule table shows two auto-opened mappings created via UPnP requests from internal devices. UPnP lets any internal device punch firewall holes without administrator review — on a network that already exposes Crestron via static port-forwards (F-01) and runs a flat LAN (F-05), that is unaudited additional exposure.
Recommendation
Disable UPnP. Any service that genuinely needs an inbound port should be an explicit port-forward — and ideally moved behind the VPN (F-02).
The open doors allow more traffic types than they need
The three openings pointed at the Crestron system currently allow two kinds of network traffic (TCP and UDP) when only one — TCP — is actually needed.
The extra traffic type is exposed surface with no benefit to how anything works.
Narrowing them to the one needed traffic type shrinks the exposed surface with zero effect on day-to-day use.
Port-forwards use TCP/UDP combined where TCP-only is appropriate
Observation
All three Crestron port-forwards (F-01) are set to Protocol = TCP/UDP. HTTPS (443) is TCP-only, and the Crestron control ports (50001, 41796) are documented as TCP/TLS services — UDP is not required. Forwarding UDP needlessly broadens the attack surface and invites UDP-based scans and amplification probes.
Recommendation
Set each rule’s Protocol explicitly to TCP. Reversible in seconds, with no functional impact on the documented Crestron services.
Sources2
Your Wi-Fi names look separated but aren’t
You have five Wi-Fi names (House, Guest, IoT, AV, Service) that suggest separation — but underneath they all connect to the same single network.
The separation is in name only, so a device on one name has the same reach as a device on any other.
This is a natural starting point for the network-lanes work above: keep the names, give each its own real lane, and rotate the Service network passphrase after each major integrator visit.
Multiple SSIDs are used as soft segregation but are not actually segmented
Observation
The five SSIDs (House, House-Guest, House-IoT, House-AV, House-Service) are all bound to the same Native Network, so clients on each land in the same 192.168.88.0/24 broadcast domain. An IoT device taken over on House-IoT has the same reach as a laptop on House.
Recommendation
A natural on-ramp to the VLAN work in F-05: keep the SSID names, bind each to its own VLAN with explicit allow/deny rules, and rotate the Service SSID passphrase (PSK) after each major integrator visit (it is shared with technicians by design).
Your internet name-lookups use the provider’s defaults
The system that translates website names into addresses is using your internet provider’s default servers, unencrypted.
Provider DNS typically offers fewer privacy and security-filtering options than a dedicated encrypted resolver.
Switching to a privacy-focused encrypted provider (like Cloudflare or Quad9) is a small quality-of-life and privacy improvement.
DNS and content filtering are at ISP defaults
Observation
WAN and Default-network DNS are set to Auto (ISP resolvers), Encrypted DNS is Off, and no CyberSecure Content Filter is bound to the LAN. ISP DNS typically offers fewer privacy and security-filtering options than Cloudflare’s and Quad9’s public resolvers; DNS over TLS and DNS over HTTPS add a confidentiality layer over plaintext DNS — worthwhile on a network that also lacks per-zone isolation.
Recommendation
Set Encrypted DNS to Cloudflare or Quad9 on the WAN, and apply the Basic Content Filter to the IoT VLAN once F-05 is in place. A quality-of-life and minor-security improvement; not urgent on its own.
Sources7
There’s no stable name for your changing home internet address
Your home’s public internet address can change without notice.
Remote-access tools that rely on a fixed address can break silently when it changes.
Setting up a stable nickname for it (Dynamic DNS) means remote-access tools keep working even when the address changes — useful once the VPN is in place.
No Dynamic DNS configured against a dynamic public IP
Observation
WAN IPv4 is DHCP-assigned by the ISP and the port-forward rules carry the standard “IP may change” warning; no DDNS service is bound to WAN1. If the public address changes, any remote-access workflow that hard-codes it silently breaks.
Recommendation
When WireGuard is stood up (F-02), configure DDNS on WAN1 with a service the integrator already manages (No-IP, DynDNS, etc.) and reference the hostname — not a literal address — in the VPN client config.
Some Apple devices show up as “new” repeatedly — this is normal
A few Apple devices in your client list show up under changing hardware IDs, which can look like “new devices” appearing over and over.
This is completely normal — it’s Apple’s Private Wi-Fi feature working as designed. Nothing here is a security problem.
No action is needed. If the repeated “new device” entries bother you, the setting can be turned off per-network on each Apple device.
Locally-administered MAC addresses consistent with Apple’s Private Wi-Fi Address feature
Observation
The tracked-client list contains six locally-administered MAC addresses (the U/L bit is set in the first octet), all fingerprinted by the controller — via DHCP option 55, vendor class identifier, and mDNS hostnames — as Apple devices. The pattern is consistent with Apple’s Private Wi-Fi Address feature, which generates a software-defined MAC per network and, in some configurations, rotates it — producing “new client” entries as the address changes. Nothing adverse was observed.
Recommendation
No action required for security. If the homeowner wants the client list to stop showing repeated “new device” entries, the Private Wi-Fi Address setting is per-network on each Apple device. Background: The mystery MACs on your UniFi network.
What’s working
The findings list isn’t the whole picture.
- Firmware is current — The UDM-Pro, the Network application, the Protect application, and all 16 infrastructure devices are on the Official channel with auto-update on.
- WAN health is excellent — The Verizon FiOS Gigabit uplink shows low-double-digit-millisecond latency to the first ISP hop and no observed loss in the visible window.
- Intrusion Prevention is active — CyberSecure IPS runs in Notify-and-Block mode with all categories selected; signatures are current.
- Region Blocking is doing measurable work — Inbound flows from blocked regions are dropped at the gateway and surface in the logs.
- WAN mode is appropriate — The single WAN is set to Failover-Only — correct for a single-ISP deployment.
- Rogue DHCP detection is on — The gateway will alert if another device on the LAN starts handing out leases.
- Spanning Tree is configured correctly — RSTP is enabled on the switches, preventing loops if a cable is miswired.
- Wi-Fi 6 hardware is current — Every access point supports WPA3 and PMF natively — which is why the Wi-Fi upgrade (F-04) is a software-only change, not a hardware refresh.
- Protect runs on a dedicated NVR — The camera workload sits on a CK-G2-Plus and is not competing with the gateway for compute or storage.
Action plan
Sequenced for the most security gain per unit of disruption.
Optional — worth a conversation, not findings
- Firmware and applications are current and on the Official channel with auto-update on — keep it that way; optionally schedule the auto-updates for low-impact hours so a reboot never lands mid-day.
- Schedule a gateway configuration-backup cadence (UniFi Site Manager → Backups) so any configuration drift after these changes is recoverable.
- Consider a UPS on the rack housing the UDM-Pro, switches, and NVR — a graceful shutdown during a power blip protects SSDs and avoids the Protect database recovery cycle.
- If the Lutron HomeWorks processor moves onto a dedicated Automation VLAN as part of F-05, verify the Lutron app still reaches it via the Smart Bridge cloud relay (no inbound port-forwarding required by design).
- When AP hardware is next refreshed, plan for WiFi 6E / WiFi 7 access points and tighten WPA3 + PMF further on the modern radios.
Your devices
The site, as inventoried.
- Site
- Manhattan-area private residence (fictional)
- Gateway
- UniFi Dream Machine Pro (UDM-Pro) · UniFi OS 4.x · Network app 9.x
- Switches
- USW Pro 24 PoE (Layer 3) · USW 16 PoE (Layer 2, uplinked off Pro)
- Access points
- 5 total — U6-Pro ×3 (living, master, dining) · U6-LR ×2 (rack, study) — all WiFi 6
- Cameras
- UniFi Protect — 8 cameras (G4 Pro ×2, G4 Bullet ×4, G4 Doorbell ×2) on a CK-G2-Plus NVR
- AV / automation
- Crestron Home processor (CP4-R) at 192.168.88.20 · Lutron HomeWorks processor at 192.168.88.30 · 2N IP Verso intercom · Sonos zones
- ISP / WAN
- Verizon FiOS Gigabit, single uplink · dynamic public IPv4 · no IPv6
- LAN
- Single network “Default” — 192.168.88.0/24, DHCP 100–250, ~55 leases in use
- Wi-Fi SSIDs
- 5 total — House, House-Guest, House-IoT, House-AV, House-Service — all bound to Native Network, all WPA2
- Clients
- 62 total (54 online, 8 offline) — 38 wired, 24 wireless
- Admin accounts
- 5 total — 2 homeowner (Super Admin) · 3 AV integrator (1 Owner + 2 Custom)
- Remote access
- 3 port-forward rules to 192.168.88.20 (Crestron) on external 8443→443, 50001→50001, 41796→41796 · From: Any · no VPN configured
References
Every technical claim, sourced.
- [1]Crestron Home Documentation — Remote System Access. Documents the current cloud-relay model for the homeowner mobile app, VPN guidance for system configuration, and the explicit recommendation to remove port mapping from the router after secure remote access is set up. docs.crestron.com/en-us/8525/Content/CP4R/Appendix/Enable-Remote-System-Access.htm
- [2]Crestron Home Documentation — Ports Used by Crestron Home. Documents the protocol scope of each port — TLS over TCP for 443, 41796 (Secure CIP), 50001 (Crestron Home App), and others. docs.crestron.com/en-us/8525/Content/Ports.htm
- [3]Lutron Support — Caséta / Smart Bridge connection FAQ. Documents that the Lutron app connects to the Smart Bridge via the cloud, and the Smart Bridge makes outbound connections only — no inbound port-forwarding is required. support.lutron.com/us/en/product/casetawireless/faqs/bridge-connection/how-does-the-lutron-app-connect-to-the-smart-bridge
- [4]Control4 — 4Sight Services. Documents 4Sight as a cloud-based subscription enabling remote access, with the note that 4Sight is available for systems installed before April 23, 2024; for systems installed after that date, Control4 Connect is the replacement service. docs.control4.com/o/4sight-services
- [5]Savant Support — Savant Pro knowledge base. Documents Savant Home Manager as a cloud application providing system access, monitoring, and dealer remote-management features. support.savant.com/pro
- [6]IEEE Registration Authority. The 802 standards family defines the 48-bit MAC address format, including the Individual/Group (I/G) and Universal/Locally-administered (U/L) flag bits in the first octet. The U/L bit is bit 1 (second-least-significant) of that octet. standards.ieee.org/products-programs/regauth/
- [7]IETF RFC 7858 — Specification for DNS over Transport Layer Security (TLS). The standards-track specification for encrypted DNS that gateways (including UniFi) reference when offering an Encrypted DNS option. datatracker.ietf.org/doc/html/rfc7858
- [8]IETF RFC 2132 — DHCP Options and BOOTP Vendor Extensions. Defines option 55 (Parameter Request List), option 60 (Vendor Class Identifier), and option 12 (Host Name). These option fields are what network controllers use to fingerprint a client’s vendor and model independent of its MAC address. datatracker.ietf.org/doc/html/rfc2132
- [9]Apple Support — Use private Wi-Fi addresses on iPhone, iPad, Apple Watch, and Vision Pro. Documents the Private Wi-Fi Address feature, the OS versions on which it ships, and the per-network toggle that turns it off where stable identification is required. support.apple.com/en-us/102509
- [10]IEEE 802.11 — Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. Protected Management Frames (management-frame protection) were introduced in the 802.11w-2009 amendment and folded into the base standard; they defend the management frames that WPA2-only networks leave unprotected, blocking the deauthentication and beacon-spoofing attacks that can knock clients offline. The Wi-Fi Alliance requires PMF on all newly certified devices. standards.ieee.org/ieee/802.11/7028/