不支援的情節
基於各種原因，Windows Communication Foundation (WCF) 不支援某些特定的安全性情節。 例如，Windows XP Home Edition 不會實作 SSPI 或 Kerberos 驗證通訊協定，因此 WCF 並不支援在該平台上使用 Windows 驗證來執行服務。 當您在 Windows XP Home Edition 下執行 WCF 時，則支援如使用者名稱/密碼與 HTTP/HTTPS 整合式驗證之類的其他驗證機制。
模擬案例
當用戶端進行非同步呼叫時，模擬的識別可能不會流動
當 WCF 用戶端在模擬下使用 Windows 驗證對 WCF 服務進行非同步呼叫時，可能會驗證用戶端處理序的識別，而非模擬的識別。
啟用 Windows XP 與安全性內容權杖 Cookie
WCF 不支援模擬，而且當下列條件存在時，則會擲回InvalidOperationException：
作業系統是 Windows XP。
驗證模式變成 Windows 識別。
OperationBehaviorAttribute 的 Impersonation 屬性會設定為 Required。
建立以狀態為基礎的安全性內容權杖 (SCT) (根據預設會停用建立作業)。
您只能透過自訂繫結來建立以狀態為基礎的 SCT ( 如需更多資訊，請參閱操作說明：為安全工作階段建立安全內容權杖。) 在程式碼中，您可以使用SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean)或SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean)方法來建立安全性繫結項目 (可能是SymmetricSecurityBindingElement 或 AsymmetricSecurityBindingElement)，並將requireCancellation參數設為false，藉此啟用權杖。 此參數會參考 SCT 的快取。 將值設為 false 會啟用以狀態為基礎的 SCT 功能。
另外，您可以在組態中建立<customBinding>，接著加入<security> 元素，並將authenticationMode 屬性設為 SecureConversation ，以及將requireSecurityContextCancellation屬性設為true，藉此啟用權杖。
注意
執行作業之前有一些特定需求： 例如，CreateKerberosBindingElement 將建立會變成 Windows 識別的繫結項目，但是不會建立 SCT。 因此，您可以將它與 Windows XP 上的Required選項搭配使用。
可能產生的 ASP.NET 衝突
WCF 和 ASP.NET 皆可啟用或停用模擬。 當 ASP.NET 裝載 WCF 應用程式時，WCF 和 ASP.NET 組態設定之間可能會有衝突。 一旦發生衝突，WCF 設定將取得優先權，除非已將Impersonation屬性設為NotAllowed的情況下，ASP.NET 模擬設定才會取得優先權。
組件載入可能會在模擬狀態下失敗
如果模擬的內容沒有載入組件的存取權，而且同時也是 Common Language Runtime (CLR) 第一次嘗試載入該 AppDomain 的組件，則 AppDomain 會快取失敗結果。 即使還原模擬後，後續的組件載入嘗試一樣會失敗，而且即使還原後的內容具有載入組件的存取權也一樣。 這是因為 CLR 並未在使用者內容變更之後重新嘗試載入。 您必須重新啟動應用程式定義域，從失敗中進行還原。
注意
WindowsClientCredential 類別的 AllowedImpersonationLevel屬性預設值為 Identification。 在大多數情況下，識別層級的模擬內容沒有載入任何其他組件的權限。 這是預設值，因此您應該要瞭解這個常見的情況。 當模擬的處理序沒有 SeImpersonate 權限時，一樣會發生識別層級的模擬情況。 如需詳細資訊，請參閱委派和模擬。
委派需要認證交涉
若要將 Kerberos 驗證通訊協定與委派搭配使用，您必須實作具有認證交涉的 Kerberos 通訊協定 (有時也稱做「多線」(Multi-leg) 或「多步驟」(Multi-step) Kerberos)。 如果您實作不具有認證交涉的 Kerberos 驗證 (有時也稱做「單次」(One-shot) 或「單支線」(Single-leg) Kerberos)，則會擲回例外狀況。 如需實作認證交涉方式的詳細資訊，請參閱偵錯 Windows 驗證錯誤。
密碼編譯
SHA-256 僅支援對應金鑰用途
WCF 支援各種不同的加密與簽章摘要來建立演算法 (您可以透過系統提供繫結中的演算法套件來指定此演算法)。 為了提升安全性，WCF 支援使用安全雜湊演算法 (SHA) 2 的演算法 (尤其是 SHA-256) 來建立簽章摘要雜湊。 此版本僅針對對稱金鑰用途 (例如 Kerberos 金鑰) 支援使用 SHA-256，而且並未使用 X.509 憑證來簽署訊息。 由於 WinFX 中的 RSA-SHA256 目前尚無法支援，所以 WCF 無法使用 SHA-256 雜湊來支援 RSA 簽章 (用於 X.509 憑證)。
不支援與 FIPS 相容的 SHA-256 雜湊
WCF 不支援符合 SHA-256 FIPS 標準的雜湊，因此在需要用到符合 FIPS 之標準演算法的系統上，WCF 並不支援使用 SHA-256 的演算法套件。
如果編輯登錄的話，與 FIPS 相容的演算法可能會失敗
您可以透過 [本機安全性設定] 之 Microsoft Management Console (MMC) 嵌入式管理單元，啟用與停用與聯邦資訊處理標準 (FIPS) 相容的演算法。 您也可以存取登錄中的設定。 然而，請注意 WCF 並不支援使用登錄來重設設定。 如果將值設為 1 或 0 以外的任意值，則 CLR 與作業系統之間就會產生不一致的結果。
與 FIPS 相容的 AES 加密限制
與 FIPS 相容的 AES 加密，在識別層級模擬底下的雙工回撥中無法發揮作用。
CNG/KSP 憑證
加密 API: 新一代 (CNG) 會長期取代 CryptoAPI。 此 API 適用於 Windows Vista、Windows Server 2008 和更新版本的非受控程式碼。
.NET Framework 4.6.1 和舊版不支援這些憑證，因為它們使用舊版 CryptoAPI 來處理 CNG/KSP 憑證。 搭配 .NET Framework 4.6.1 和舊版使用這些憑證會導致例外狀況。
有兩種可能的方式可以判斷憑證是否使用 KSP：
對
p/invoke執行CertGetCertificateContextProperty後，檢查所傳回dwProvType的CertGetCertificateContextProperty。從命令列使用
certutil命令來查詢憑證。 如需詳細資訊，請參閱管理憑證的 Certutil 工作。
如果需要使用 ASP.NET 模擬與 ASP.NET 相容性的話，訊息安全性就會失敗
WCF 並不支援系列設定組合，因為這些組合可能會讓用戶端驗證無法進行：
已啟用 ASP.NET 模擬。 在 Web.config 檔案中將
<identity>元素的impersonate屬性設為true，即可完成此作業。ASP.NET 相容性模式是藉由將<serviceHostingEnvironment> 的
aspNetCompatibilityEnabled屬性設定為true來啟用。已使用訊息模式安全性。
解決辦法就是關閉 ASP.NET 相容性模式。 或者，如果還需要 ASP.NET 相容性模式，則停用 ASP.NET 模擬功能並改用 WCF 提供的模擬功能。 如需詳細資訊，請參閱委派和模擬。
IPv6 常值位址失敗
安全性要求會失敗的情況為：當用戶端與服務位於同一部電腦，以及服務使用 IPv6 常值位址時。
如果服務與用戶端位於不同的電腦上，則 IPv6 常值位址就能正常運作。
WSDL 擷取聯合信任時失敗
針對聯合信任鏈結中的每個節點，WCF 都只需要一份 WSDL 文件。 指定端點時，請小心不要設定迴圈。 一個可能發生迴圈的方式是，使用 WSDL 來下載同一份 WSDL 文件中有兩個以上連結的聯合信任鏈結。 會產生這個問題的常見案例是，Security Token Server 和聯合服務包含在相同的 ServiceHost 中。
舉例來說，當服務具有下列三個端點位址時，就會發生這種狀況：
http://localhost/CalculatorService/service(服務)http://localhost/CalculatorService/issue_ticket(STS)http://localhost/CalculatorService/mex(中繼資料端點)
這會擲回例外狀況。
您可以藉由將 issue_ticket 端點放在其他位置，來解決這個狀況。
WSDL 匯入屬性可能會遺失
WCF 在執行 WSDL 匯入時，會遺失 <wst:Claims> 範本中 RST 項目的屬性。 如果您是在 <Claims> 或 WSFederationHttpBinding.Security.Message.TokenRequestParameters 中直接指定 IssuedSecurityTokenRequestParameters.AdditionalRequestParameters，而不是直接使用宣告類型集合，在 WSDL 匯入期間就會發生這個狀況。 因為匯入作業會遺失屬性，繫結無法透過 WSDL 適當往返，也因此繫結在用戶端是不正確的。
解決方式是匯入之後直接在用戶端修改繫結。