The page contains critical information about how the Knox 3.x framework handles passwords.

Enforcing password overview

The Knox framework does not enforce a password requirement by default for new Workspaces created under Knox 3.x.

Certain items depend on password being created. For example, Android Key Store (AKS) cannot initialize unless a password is created. Thus, EMM agents cannot provision certificates unless user has set up a password. Similarly cert enrollment using SCEP or other mechanism also requires password to be setup.

EMMs must wait until a password is created before proceeding with items that require password. IT admin MUST specify password policy prior to container creation. Use the following Knox mechanisms to allow specifying password policy.

  1. KnoxConfigurationType
  2. PasswordPolicy

Note: Workspace prompts users to set their password when it launches.

After the user changes the device or profile password, the onPasswordChanged() method is called as a result of receiving the ACTION_PASSWORD_CHANGED status. EMMs can implement this method to know when password has been set. Use the following sample code to get the userId of the user that changed the password.

Public void onPasswordChanged(Context context, Intent intent, UserHandle user) {
 int containerId = intent.getExtras().getInt("android.intent.extra.USER_ID");

After receiving notification of password change and determining the user that changed the password EMMs can proceed to configure or provision items that require password. For example, after this notification EMMs can start provisioning certificates.

Password updates

Samsung Knox SDK provides wrapper APIs for specific DPM methods. One such API is BasePasswordPolicy.resetPassword() which provides the functionality for Android’s DPM.resetPassword() method. Android has deprecated DPM.resetPassword() from Android O onwards and recommends using DPM.resetPasswordWithToken(). However for token APIs, the caller must be a Device Owner(DO) or Profile Owner(PO).

Impact to Partners

Both existing deployments on Android O and upgrades to Android P are impacted.

Android O (8.1 with Knox 3.0)

Due to design changes in Android keystore in Android 8.1, if resetPassword API is called the keystore is corrupted. Certificates needed for email, VPN, etc. are not guaranteed. If resetPassword is called on Android 8.1 the device will need to re-enroll.

Android P (9.0 with Knox 3.2.1)

As Android has deprecated DPM.resetPassword and limited DPM.resetPasswordWithToken to Device Owner(DO) and Profile Owner(PO). DA based solutions that upgrade from Adnroid O to Android P have no mechanism to reset password.

Recommendation for Partners

For partners that are Device Owner (DO) or Profile Owner (PO) we recommend using DPM.resetPasswordWithToken For partners that are DA based solution starting with Android P (Knox 3.2.1) Samsung Knox SDK will provide another wrapper API BasePasswordPolicy.resetPasswordWithToken. We recommend EMM partners to use the new BasePasswordPolicy.resetPasswordWithToken() for their existing DA deployments.


In order to use BasePasswordPolicy.resetPasswordWithToken(), the token must be set first using the BasePasswordPolicy.setResetPasswordToken() method. IT admins must ensure the user confirms their credentials after setting the token or it will not be active. Please see the following note from the Google’s API guide for more information. If the user currently has a lockscreen password, the provisioned token will not be usable until after the user performs a confirm credential operation triggered by KeyguardManager.createConfirmDeviceCredentialIntent(CharSequence, CharSequence).

Our recommendation is to ask users to confirm their credentials after token is set otherwise the end users will be required to remember their password during this upgrade. If a user forgets their password prior to a MDM (UEM) having set the token, the only option is to factory reset the device. The impact of this is limited to DA based devices upgrading from Android O to P.

In Knox 3.0 password is not enforced during creation. IT admins can set a password policy for the user to set the password after Workspace is launched for the first time.

Note: Starting with Knox 3.0, EMM’s DeviceAdminReceiver for CL and COM containers, located in user 0, gets all the callbacks that a DPC that is running inside the managed profile would get. For example: onPasswordChanged or onEnabled.

The below screenshots show the Knox 2.x password flow.


Enforcing password in Workspace 3.2.1

section here

Enforcing password in Workspace 3.0 - 3.2

Knox SDK v3.0 password rules have been modified to extend the functionality of upgrading from an Android PO to a Knox Workspace. As a result, the Workspace password flow has changed and passwords are not enabled by default. This also allows developers to customize their own authentication solution. To ensure a user sets a password on their container, insert the code below in the AdminReciever class.

public void onProfileProvisioningComplete(Context context, Intent intent) {	
   EnterpriseDeviceManager edm = EnterpriseDeviceManager.getInstance(context);
   PasswordPolicy pp = edm.getPasswordPolicy();

Now a user is prompted to create a password prior to entering the container when a PO is upgraded to a Knox container, with the license activation method.

The container can also be configured to set a password lock delay using setMaximumTimeToLock.


Set Password in Workspace 2.9 and below

If you are using Knox SDK v.2.9 or lower, password is enabled by default. For more information on setting the password in such cases, see the following section.

To set a password for a Knox Workspace, ensure that the container is configured properly prior to being created. This example clones a knox-b2b container.

KnoxConfigurationType predefinedConfiguration = KnoxContainerManager.getConfigurationTypeByName("knox-b2b");
KnoxConfigurationType newConfig = predefinedConfiguration.clone("custom"); //Clones and assigns a new name

Change Password on device side

The following configurations must be enforced by the IT admin:

  • Set password change timeout
  • Set password expired date
  • Enforce password change

Perform the following procedure:

  1. Create the EnterpriseDeviceManager object.
  2. Get the PasswordPolicy object.
  3. Use setPasswordChangeTimeout and pass in the amount in minutes.
  4. Get the enterpriseDeviceAdmin
  5. Set the password expiration date with setPasswordExpires. Pass in the amount in days.
  6. Enforce a password change with enforcePwdChange.
EnterpriseDeviceManager edm = EnterpriseDeviceManager.getInstance(context);
PasswordPolicy passwordPolicy = edm.getPasswordPolicy();


//EDMTestsAdmin extends DeviceAdminReceiver and is notified when password expires
ComponentName enterpriseDeviceAdmin = new ComponentName(context, EDMTestsAdmin.class); 

passwordPolicy.setPasswordExpires(enterpriseDeviceAdmin, 10);