Royal Apps

I would like to highlight a security loophole in Royal TS where credentials saved in a document can be accessed or used without password protection or encryption. We are aware that we can have a registry key configured to require a password when creating a credential in a document—which is a good security measure— However, there is a security concern in the following scenario. If a user sets a password, creates a credential, and then removes the password (encryption) afterward, the credential remains accessible without requiring a password. This exposes all stored credentials.

Unfortunately, as currently implemented, lockdown does not fully address our concern: a user who knows (and has write permission for) the original document password can still remove that password and save the document unencrypted, exposing all stored credentials. Lockdown merely limits who can view or edit credentials once it’s active, but it does not prevent the act of disabling encryption itself.

To close this gap, we’d like to propose adding an administrative policy (for example, a registry key or group‑policy setting) that enforces the following behavior:

Scope: Only applies to documents that contain one or more credential objects.
Behavior: When the policy is enabled, any attempt to remove or disable the document password on a credentials‑bearing document is blocked and the change cannot be saved.
Exclusion: Documents without credential objects remain unaffected—you won’t force users to set a password on non‑sensitive files.

For instance, a registry setting could look like below:
"PolicyDoNotAllowRemovePasswordInDocumentsWithCredentialObjects"="True" under [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\RoyalApps\RoyalTS\Default\RoyalApplicationSetting]

When set to True, trying to clear the password/encryption on a document that stores credentials would produce an error such as:

“This document contains credential entries and must remain encrypted. Password removal is disabled by policy.”

This approach ensures that no document containing sensitive data is ever left unencrypted, while maintaining a frictionless experience for ordinary, non-credential files. We are aware of the registry key that enforces password protection on all documents; however, if a document does not contain credentials, it does not require enforced password protection.

Could your team consider implementing such a policy in a future update? We believe it would comprehensively close the loophole without over‑restricting users.

Thanks for considering this enhancement—happy to discuss further!

Kind regards,
Armin

Hi Stefan, 
Thanks for the reply and for clarifying the role of the additional lockdown password. That definitely helps explain how lockdown works once it’s enabled. However, I believe there’s still a key point that may have been misunderstood. Let me break it down with a scenario that is currently possible:

1. A user sets a password for a Royal TS document.
2. The user creates and stores credential objects inside the document (now encrypted).
3. The same user, at any time, removes the document password—after providing the lockdown password or disabling this feature—thereby effectively decrypting the document.
4. All credential objects remain in the document are now unprotected.

Appreciate the response. Of course, user training is essential—and we actively invest in it—but relying solely on individual behavior is not a sufficient control when sensitive data and company risk are involved. Training, by nature, depends on consistent human behavior, which is always a variable.

That’s exactly why we’re advocating for an enforcement option here. It’s about putting safeguards in place to prevent potentially risky actions before they happen. When dealing with sensitive or regulated data, it’s not realistic to expect every user to make the right decision every time. Enforcement helps fill that gap.

This feature wouldn’t replace training—it would complement it, providing a policy-aligned backstop that reduces the risk of human error. In environments where security and compliance are critical, having this option isn’t just helpful—it’s essential.

We believe this would be a meaningful improvement for organizations that need to manage risk proactively, and we’d welcome continued discussion if others in the community feel the same.
Thanks in advance for your support.