Encrypt a Windows SMB Share on Windows 10 and 11: PowerShell Setup and Connection Verification

The important distinction is that this is encryption in transit, not encryption at rest. If the host PC or its disk is stolen, SMB Encryption does not protect files stored locally; BitLocker is the Windows feature designed for that job. But for traffic crossing your LAN, guest VLAN, or a site-to-site link, it is a sharp and built-in safeguard.

This guide encrypts one shared folder rather than imposing encryption across the whole PC. That is usually the right first move: narrowly scoped, easy to test, and less likely to break an older NAS or legacy device that only speaks an outdated SMB dialect.

What you need before starting​

You need two Windows PCs:

Quick walkthrough

• A host PC that contains the folder and will share it.
• A client PC that will connect to that share.
• Administrator rights on the host PC.
• A private, trusted network profile—not a coffee-shop Wi‑Fi connection wearing a fake moustache.
• SMB 3.0 or later support at both ends of the connection.

SMB Encryption arrived with SMB 3.0. Windows 10 and Windows 11 support it, but a client or server limited to SMB 2.x cannot use it. If encryption is required and the other device cannot negotiate SMB 3 encryption, Windows should refuse the connection rather than quietly downgrading the protection.

Note: Windows 11 version 24H2 includes newer client-side options to require encryption for all outbound SMB connections. That is useful for managed environments, but it is broader than this guide. Here, the host requires encryption only for the share you select.

Click to expand...

Step 1: Prepare or identify the folder to share​

On the host PC, create a folder to use for the share if you do not already have one. For example:

C:\SecureShare

Before sharing it, decide who needs access. SMB share permissions and the folder’s NTFS permissions both matter. A user needs sufficient rights in both places; the most restrictive effective permission wins.

For a home or small-office test, use a specific local account or a Microsoft-account-based Windows sign-in that exists on the host. Avoid granting broad write access to Everyone unless this is an intentionally open, low-risk test folder.

Step 2: Check the current SMB share configuration​

Open Windows PowerShell as Administrator on the host PC. Then list existing shares:

Get-SmbShare

If you already have a share, replace SecureShare with its actual share name and inspect it:

Get-SmbShare -Name "SecureShare" | Select-Object Name, Path, EncryptData

If EncryptData is False, the share is not currently forcing encrypted SMB sessions. If it is True, the share is already configured correctly and you can skip to the connection test.

You can also confirm that the Windows SMB server has SMB 2/3 enabled:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, EncryptData

EnableSMB2Protocol must be True; despite that slightly misleading label, it governs the modern SMB 2 and SMB 3 protocol family. Do not enable SMB 1 just to make an old device connect. SMB 1 has long been considered obsolete and is not installed by default on modern Windows releases.

Step 3: Create an encrypted share with PowerShell​

If the folder is not yet shared, this is the cleanest route. Run the following on the host PC, changing the folder path and account name to match your environment:

New-SmbShare -Name "SecureShare" `
 -Path "C:\SecureShare" `
 -FullAccess "HOSTPC\YourUserName" `
 -EncryptData $true

For example, if the host computer is named OFFICEPC and your account is Alex, the access setting would be:

-FullAccess "OFFICEPC\Alex"

New-SmbShare exposes the folder through SMB, and its -EncryptData option makes encryption mandatory for that share. Microsoft’s SMB PowerShell documentation specifically supports creating a share with this setting enabled.

Encrypt an existing shared folder instead​

If the share already exists, do not delete and recreate it just to add encryption. Use:

Set-SmbShare -Name "SecureShare" -EncryptData $true

Then confirm the setting:

Get-SmbShare -Name "SecureShare" | Select-Object Name, Path, EncryptData

Expected result:

Name Path EncryptData
---- ---- -----------
SecureShare C:\SecureShare True

The Set-SmbShare cmdlet’s -EncryptData parameter controls whether the individual SMB share is encrypted.

Step 4: Make sure the host can accept file-sharing connections​

The host needs File and Printer Sharing permitted through its firewall. Windows generally configures the appropriate firewall rules when sharing is enabled, but security software or custom firewall policies can still interfere.

On the host:

• Open Windows Defender Firewall with Advanced Security.
• Select Inbound Rules.
• Ensure the relevant File and Printer Sharing rules—particularly SMB-In—are enabled for your network profile.

Do not “solve” an SMB problem by turning off Windows Firewall. That trades a connectivity annoyance for a security problem, which is rather like fixing a squeaky door by removing the front wall. Windows documentation identifies SMB TCP port 445 as required for access to shared folders.

Step 5: Connect from the second Windows PC​

On the client PC, open File Explorer and enter the share path in the address bar:

\\HOSTPC\SecureShare

Replace HOSTPC with the name of the computer hosting the folder.

If name resolution is unreliable, use the host’s IP address temporarily:

\\192.168.1.50\SecureShare

Using the host’s proper computer name is preferable for normal use, especially in managed environments where name-based authentication and identity protections matter.

When prompted, sign in with an account that has permission to access the host’s shared folder. Copy a small test file into the share, then open it from the host to confirm that both connectivity and write permissions are working.

You can map it as a drive if desired:

• In File Explorer, select This PC.
• Choose Map network drive.
• Choose a drive letter.
• Enter \\HOSTPC\SecureShare.
• Select Connect using different credentials if necessary.
• Sign in with an account authorized by the host.

Step 6: Verify that the active SMB session is encrypted​

This is the part people skip—and then merely hope their settings worked. Verify it.

Keep the shared folder open or copy a file so the client has an active connection. On the client PC, open PowerShell and run:

Get-SmbConnection | Select-Object ServerName, ShareName, UserName, Dialect, Encrypted

Look for the row for SecureShare. A successful encrypted session should show:

Encrypted: True

You should also see an SMB 3 dialect, such as 3.0, 3.02, or 3.1.1. Get-SmbConnection reports active connections from the Windows SMB client, including the negotiated dialect and whether the session is encrypted.

For a more focused check:

Get-SmbConnection |
 Where-Object ShareName -eq "SecureShare" |
 Select-Object ServerName, ShareName, Dialect, Encrypted

What success looks like​

If the connection succeeds but Encrypted is False, disconnect from the share, close open File Explorer windows, then reconnect. Confirm you changed the correct share on the correct host.

Common problems and sensible fixes​

“The network name cannot be found”​

First, confirm the host name and share name:

Get-SmbShare

Then test the UNC path using the host’s IP address. If IP access works but the computer name does not, the issue is name resolution—not encryption.

Also check that the host’s network is set to Private where appropriate, and that File and Printer Sharing firewall rules are enabled.

“The specified network password is not correct” or access is denied​

This is usually a permissions issue. Confirm:

• The credentials entered on the client are valid on the host.
• The SMB share permissions grant that user access.
• The folder’s NTFS Security permissions also grant that user access.

Encryption does not replace access control. It protects the trip, not the guest list.

The client cannot connect after encryption is enabled​

This is expected if the client is too old or is actually a NAS, media box, scanner, or other device without SMB 3 encryption support. Per-share SMB encryption is intentionally strict: devices that cannot negotiate the required security cannot access the encrypted share.

Do not weaken the encrypted share just to accommodate an obsolete device without weighing the risk. A safer answer may be a separate, limited-access compatibility share for that device—ideally on a segmented network—while sensitive files remain on the encrypted share.

You need to undo the change​

To allow unencrypted SMB connections to the share again:

Set-SmbShare -Name "SecureShare" -EncryptData $false

That may restore compatibility, but it also removes confidentiality for SMB data in transit on that share. Treat it as a deliberate rollback, not a troubleshooting reflex.

The practical security payoff​

Per-share SMB Encryption is an excellent fit when a Windows 10 or Windows 11 PC hosts sensitive working files—financial records, project documents, backups, or HR material—and another Windows computer accesses them over the network.

It is not a replacement for:

• BitLocker for lost or stolen drives.
• Strong Windows account passwords and appropriate folder permissions.
• A secure router and Wi‑Fi configuration.
• Regular Windows security updates.
• Backups that are protected from ransomware and accidental deletion.

But it closes a real gap: without SMB Encryption, an attacker able to observe or interfere with SMB traffic may have an opportunity to inspect or tamper with network file operations. SMB Encryption supplies confidentiality and integrity protection for the SMB data exchange, while Windows negotiates the best mutually supported encryption capability between compatible endpoints.