SSP/APs vs. SSPs

Security packages are deployed in one of the following types of dynamic-link libraries (DLLs):

Whether a security package is in a security support provider/authentication package (SSP/AP) or a security support provider (SSP) DLL is determined by the types of security services it provides and the extent to which it requires integration with the Local Security Authority (LSA). These differences also determine the API implemented in a custom security package.


An SSP/AP is a DLL that contains one or more security packages and can function as an SSP for client/server applications and as an authentication package for logon applications. To function in both of these roles, SSP/APs are loaded into the LSA process space at system startup and can be loaded into client/server application processes as well.

Custom SSP/AP security packages must implement both the Functions Implemented by User-mode SSP/APs, and Functions Implemented by SSP/APs. These function implementations can make use of LSA support functions to offer advanced security features such as token creation, supplemental credentials support, and pass-through authentication.

If a custom SSP/AP security package provides the full range of message integrity and privacy functions, it will also implement the Functions Implemented by User-mode SSP/APs.


An SSP is a DLL that contains one or more security packages that provide authenticated connection, message integrity, and message encryption services to client/server applications. SSPs implement Security Support Provider Interface (SSPI) functions. Applications can access the security packages in an SSP by calling the SSPI functions directly. SSPs are loaded into the client and server processes; they are not integrated with the LSA.