@oopslemon  NiFi only encrypts and obscures values in properties that support sensitive properties (so those properties which are specifically coded as sensitive properties like "password" properties). So there is no way at this time to encrypt all or portions of property values not coded as sensitive.  Keep in mind it is not just what is visible in the UI, your unencrypted passwords will be in plaintext with the NiFi flow.xml.gz file as well. My recommendation to you is to use mutual TLS based authentication instead.  You can create a clientAuth certificate to use in your rest API calls.  Then you need to make sure that your clientAuth certificate is authorized to perform the actions the rest-api call is making.  This is not going to be possible while using the single user login mode as it does not allow you to setup additional users and authorizations.  This single users authentication and authorization providers where added to protect users from unprotected access to their NiFis.  It was not meant to be the desired choice when securing your NiFi.  It is one step above an unsecured default setup that existed prior to NiFi 1.14.  It protects you, but also has limitations that go with its very basic functionality. So step one is to switch to another method of authentication and authorization to you NiFi.  TLS is always enabled for authentication as soon as NiFi is configured for HTTPS.  You can configure additional authentication methods like ldap/AD. https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication The authorizer configured in the authorizers.xml file allows you to establish policies that control user/client permissions. https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#multi-tenant-authorization   Then you can configure your invokeHTTP processor to simply use a SSLContextService that you would configure with your clientAuth certificate keystore and a truststore.  The password fields in this controller service would be encrypted.  No more need to constantly get a new bearer token.  All you need to worry about is getting a new client certificate before the old one expires which is typically every 2 years, but that is configurable when you create it and get it signed. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more