Idea for fixing a Security Loophole for stored credentials

Feature Requests Royal TS (for Windows)
1

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 mustremain 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. Weare aware of the registry key that enforces password protection on alldocuments; however, if a document does not contain credentials, it does notrequire 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

2

Hi Armin!

Thanks for the feedback.

You wrote:

…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.

I’m not sure I understand this statement. In lockdown mode, there are actually two passwords. The additional lockdown password is required to remove the encryption - without that password the situation you outline, cannot happen.

Does that make sense?

Regards,

Stefan

3

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.

In this case, credentials that were once encrypted can later be exposed if the user decides (and is permitted) to remove the password protection—provided they know both the document and lockdown passwords.

While lockdown controls who can make changes, it does not enforce continued encryption of documents containing credential objects. That’s why we propose introducing a setting—such as a registry key—that performs an additional check when encryption is being removed. If any credentials are detected within the document, the removal of encryption would be blocked.

4

Well, there are use cases where this makes sense and users have to be aware about how changes to encryption may impact files. If a user password protects a Word document, and later removes the password protection again, he must be aware of the impact. I think it’s advisable to properly train people using products with sensitive information to ensure they all act in the most responsible way possible. In any case, I’m happy to leave this thread open for further discussion. If other users feel that this is something we should address, I’m happy to get more feedback.

5

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.

6

I think a solution to this and I recognize that it is a little crazy. If you invest in Royal Server and use the document store, I think you can force the policy that way.

7

Hi Steven,
I really appreciate your input and the thought you’ve put into this. That’s a different product, of course. The one we’re discussing already has similar settings configured for purposes close to this. The idea was to enhance the current product, not abandon it over a small feature request that could improve its overall security. It would be great if this can be considered for future development.