Unmanaged 程式碼
某些程式庫程式碼需要呼叫進入 Unmanaged 程式碼 (例如，Win32 之類的機器碼 API)。 由於這表示程式碼已經超出 Managed 程式庫的安全性界線之外，因此需要格外謹慎。 如果您的程式碼為安全性中性，則您的程式碼和任何呼叫它的程式碼，都必須擁有 Unmanaged 程式碼使用權限 (指定了 UnmanagedCode 旗標的 SecurityPermission)。
然而，讓您的呼叫端擁有如此強大的使用權限通常是不太合理的。 在這類情況下，您的受信任程式碼可以扮演中介者的角色，如同設定包裝函式程式碼的安全性中說明的 Managed 包裝函式或程式庫程式碼。 如果基礎 Unmanaged 程式碼功能安全無虞，就可直接將它公開，否則便須先執行適當的使用權限檢查 (需求)。
如果您的程式碼呼叫進入 Unmanaged 程式碼，但是您不想讓您的呼叫端擁有存取 Unmanaged 程式碼的使用權限，您就必須判斷該權限。 判斷提示會封鎖您框架上的堆疊查核行程。 這個過程中您必須小心，不要製造安全性漏洞。 通常，這代表您必須要求呼叫端的適當使用權限，然後再使用 Unmanaged 程式碼執行使用權限允許的動作。 在某些情況下 (例如，取得當天時間的功能)，Unmanaged 程式碼可以直接公開給呼叫端，而不需執行任何安全性檢查。 不論是哪一種狀況，可進行判斷的任何程式碼都必須承擔維護安全性的責任。
由於任何可以提供進入機器碼之程式碼路徑的 Managed 程式碼都是惡意程式碼的潛在目標，因此在判斷哪一個 Unmanaged 程式碼可以放心使用時，必須要非常小心。 一般來說，Unmanaged 程式碼不應直接公開給部分受信任的呼叫端。 針對在可由部分受信任程式碼呼叫的程式庫中使用 Unmanaged 程式碼的安全狀況進行評估時，有兩個主要考量事項：
功能。 Unmanaged API 是否提供不允許呼叫端執行具有潛在危險性作業的功能？ 程式碼存取安全性利用使用權限來強制使用資源的存取權，因此請考量 API 是否使用檔案、使用者介面或執行緒處理，或者它是否公開受保護的資訊。 如果是，包裝它的 Managed 程式碼就必須要求必要的使用權限，然後才能允許您將它輸入。 此外，在沒有使用權限的保護時，記憶體的存取必須限制為嚴格的型別安全 (Type Safety)。
參數檢查。 一般的攻擊會將未預期的參數傳遞到公開的 Unmanaged 程式碼 API 方法，試圖使它們不按規格作業。 使用超出範圍的索引或位移 (Offset) 值的緩衝區滿溢 (Buffer Overrun) 是這種攻擊的典型範例，而可能利用基礎程式碼錯誤的任何參數也是。 因此，即使對於部分受信任呼叫端而言，Unmanaged 程式碼 API 功能上安全無虞 (在執行必要的需求之後)，Managed 程式碼也必須徹底檢查參數的有效性，確保惡意程式碼不可能利用 Managed 程式碼包裝函式層發出錯誤的呼叫。