All MID Servers go down if "Use CyberArk as secure provider" is configured and we're trying to upgrade JavaPasswordSDK.jarSummaryThe MID Server needs the username and password details to communicate with the instance in a SOAP request. In this case, since the MID Server is configured in secure config mode, the username and password is fetched from CyberArk vault each time. When a user modifies an existing CyberArk client entry at the instance (eg. JavaPasswordSDK jar) in order to upgrade to new version, then the MID Server deletes older JavaPasswordSDK.jar from its extlib folder and downloads the new jar from the instance. When downloading JavaPasswordSDK.jar, the MID Server needs a connection to instance, which consequently requires a username and password. Since this username and password is not stored in the MID Server, it tries to fetch the information from CyberArk vault. To fetch the password from the CyberArk vault, the MID Server requires the JavaPasswordSDK jar. However, that jar was deleted in the previous step. This fetch attempt causes a cyclic dependency and the MID Server goes down.ReleaseThis fix is supported in all versions, starting with the Utah family release.InstructionsSolution: Check the following configuration parameter in the config.xml: <parameter name="mid.secure_config.provider" value="com.service_now.mid.services.config.CyberArkSecuredConfigProvider"/> Use the following steps to perform the upgrade if a secured config parameter provider is configured to avoid MID Server down. Rename the CyberArk client version to JavaPasswordSDK_MajorVersion_minorVersion_patchNum.jar.Create a new jar entry in the ecc_agent table where the rename jar can be attached. This new entry downloads to the MID Server. This step results in two jar (Passworsdk.jar and JavaPasswordSDK _12_X_X.jar).Delete old ecc_agent entry from instance. This step deletes Passworsdk.jar from the MID Server, and the JavaPasswordSDK _12_X_X.jar remains in the system.