Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


If a Windows network profile is stuck on Public for a trusted home or small-office connection, identify the active adapter and connection profile before changing anything. Set only that trusted profile to Private through Settings or supported PowerShell, then disconnect and reconnect to verify persistence. Do not make an airport, hotel, café, shared residence, or unknown network Private merely to expose a device or make an app work.
Key Takeaways
- Public is the safer default; Private increases local discoverability on a network you trust.
- Match the profile to the active Wi-Fi or Ethernet interface, not just a familiar network name.
- Use Settings first, then supported PowerShell with a precise profile identifier and readback.
- Do not disable Windows Firewall or force a DomainAuthenticated profile.
- A setting that reverts may be owned by domain authentication, policy, management, or a recreated connection.
The device and app troubleshooting guide explains how to change one layer at a time. This article addresses an incorrect category on the current connection. It does not replace a full Windows network reset or diagnose an app that cannot reach the internet while the rest of Windows works.
Microsoft describes Public as the recommended default: the PC is hidden from other devices and is not available for ordinary file and printer sharing. Private makes the PC discoverable and should be used only when you know and trust the people and devices on the network.[1] The category is a trust decision, not a performance switch.
Use Private for a home LAN you administer or a controlled small-office LAN whose members and router you trust. Keep Public for public Wi-Fi, guest networks, hotel Ethernet, conference networks, shared-building service, tethering offered by someone else, or any connection whose local participants are unknown. A network name that resembles your home name is not sufficient proof; confirm the router, expected gateway, and physical location.
Changing to Private does not itself enable every share. Discovery, file sharing, printer sharing, application permissions, and firewall rules remain separate. Conversely, an application failure does not prove the category is wrong. If only one app is offline, use the Windows apps cannot connect guide before changing trust boundaries.
Open Settings > Network & internet. For Wi-Fi, select Wi-Fi and the connected network. For Ethernet, select Ethernet and the active connection. Record the displayed network name, adapter type, profile type, IP address, and gateway. Microsoft documents this path for selecting Public or Private.[1]
Windows may have Wi-Fi, Ethernet, a dock, mobile hotspot, virtual switch, and VPN adapters at the same time. A profile with a familiar name can belong to an inactive adapter. Temporarily avoid attaching or removing adapters while gathering evidence, and do not change every profile in bulk.
Open an ordinary PowerShell window and run Get-NetConnectionProfile. Record Name, InterfaceAlias, InterfaceIndex, NetworkCategory, IPv4 connectivity, and IPv6 connectivity for the active row. Reading does not require changing the system. If multiple rows look active, match the interface alias and index to the adapter shown in Settings.
If the category is already Private but discovery or sharing still fails, stop treating the profile as stuck. Check the relevant app, discovery setting, share permission, and firewall rule instead. The firewall explainer describes why changing a network label and allowing a service are different decisions.
On a trusted network, select Private network under Network profile type for the active Wi-Fi or Ethernet connection. Leave Microsoft Defender Firewall enabled. Microsoft warns that turning the firewall off can make the device more vulnerable to unauthorized access.[2]
Close Settings, reopen the same active connection, and confirm it still reads Private. Then disconnect and reconnect once: for Wi-Fi, disconnect from that SSID and reconnect; for Ethernet, disable and re-enable the adapter through supported controls or unplug and reconnect the cable once. Do not reboot the router or reset all network adapters for this first check.
Run Get-NetConnectionProfile again and verify that the same InterfaceIndex or intended profile now reports Private. Test only the local function you actually need, such as discovery of a known home printer. Do not turn on broad sharing or password-free access simply because the category changed.
If the Private option is absent, disabled, or immediately reverts, record the exact screen and move to ownership checks. Repeated clicking is not evidence and may hide a policy refresh.
Microsoft's Set-NetConnectionProfile cmdlet changes the category for a connection profile and accepts a precise interface index, alias, name, or input object.[3] Open PowerShell as administrator only after identifying the exact trusted profile. First read the profile, then target one row—for example, pipe the selected profile object to Set-NetConnectionProfile -NetworkCategory Private or use its unique -InterfaceIndex.
Avoid scripts that change every profile returned by a wildcard. Do not paste commands that disable the firewall, edit undocumented registry values, delete Network List Manager keys, or remove adapters. Keep the original profile details so you can return it to Public if you selected the wrong connection.
Immediately run Get-NetConnectionProfile again. The command succeeding without an error is not enough; the readback must show Private for the intended active row and must leave other profiles unchanged. Reconnect once and repeat the readback.
If PowerShell says access is denied, a parameter is invalid, or policy prevents the change, preserve the exact error. Do not take ownership of registry keys or bypass device management. On a work or school PC, send the profile details and error to IT.
Microsoft states that DomainAuthenticated is assigned automatically when the network authenticates to a domain controller and cannot be set manually with Set-NetConnectionProfile.[3] Do not try to force a domain category to solve discovery. If a domain-joined computer shows Public at the office, the relevant questions include domain-controller reachability, DNS, secure channel state, and organizational policy; those belong to administrators.
Group Policy, mobile-device management, endpoint security software, and corporate network agents can enforce categories or firewall profiles. A setting that changes briefly and reverts at policy refresh is evidence of an owner, not permission to remove the control. Record whether the behavior occurs before or after VPN sign-in, docking, domain authentication, or a scheduled management refresh.
The same applies to a personal computer managed by an employer. Ownership of the hardware does not necessarily mean ownership of its security configuration. Preserve firewall protection and escalation evidence.
AethoVPN can protect supported traffic after Windows selects a working network, but it should not be used to disguise a local network as trusted or to override Windows domain and firewall policy.
First determine whether Windows retained the same profile. A changed router, new Wi-Fi security mode, different Ethernet gateway, USB dock replacement, cloned SSID, or network-driver reinstall can make Windows identify a connection as new. The new profile may correctly start as Public even though its display name looks familiar.
Compare Name, InterfaceAlias, InterfaceIndex, gateway, and connection time before and after reconnecting. If a second profile appears, change only the verified trusted one. Forgetting and reconnecting to Wi-Fi deliberately creates fresh identity state and is not the first remedy.
Next check whether a policy or domain event explains the transition. Review Event Viewer only if you know the relevant time window; do not clear logs. Capture the Windows edition and build, whether the device is domain joined or managed, adapter model and driver version, and the exact point at which the category changes.
Use a network reset only when broader networking is broken and simpler adapter-specific checks have failed. Resetting removes and reinstalls network adapters and can erase configuration; it is disproportionate for a profile that can be changed and retained through supported controls.
Set-NetConnectionProfile only with a precise target and readback.No. The category primarily changes trust and applicable firewall behavior. It is not a bandwidth or latency mode.
Only if you control the network and trust its participants. A landlord, guest, or shared-building network may still be better treated as Public.
You may be viewing an inactive adapter, using a managed device, or encountering a different Windows build. Identify the active connection and check policy ownership.
No. Microsoft documents that Windows assigns it automatically after domain authentication; the cmdlet cannot set it manually.
No. Keep it enabled and inspect the specific app or sharing rule. Turning it off broadens exposure and does not prove the profile is fixed.
Windows may have created a new profile, domain or management policy may have refreshed, or the adapter identity may have changed. Compare exact profile details.
It may recreate adapters and profiles, but it is a broad disruptive step. Use it only for wider networking failures after preserving configuration.
Send the Windows build, adapter, connection name, interface index, category before and after reconnecting, management status, timestamps, and any exact PowerShell error.
Sources checked 12 September 2026.
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.





