Royal TS/TSX and Royal Server: Security, Encryption, and Vendor Information

Knowledge Base
1

Royal TS/TSX and Royal Server: Security, Encryption, and Vendor Information

Applies to: Current stable Royal TS 7.x, Royal TSX 6.x, and Royal Server 5.x releases
Not covered: Beta releases and Royal Connect
Last reviewed: August 14, 2026

This article provides product and vendor information for customers performing security reviews or completing vendor questionnaires. It describes current Royal Apps product behavior and engineering practices. It is not an independent security assessment, audit report, certification, or contractual security commitment.

Security overview

Royal TS and Royal TSX are locally installed client applications. Connections, credentials, tasks, and related configuration are stored in file-based Royal documents under the customer’s control. Royal Server is an optional, customer-operated Windows server product that can centrally host Royal documents and provide access controls, a Secure Gateway, and other management functionality.

Royal documents and the credentials stored in them are not uploaded to or stored in a Royal Apps-hosted credential service. Royal Apps does operate optional online services used for purposes such as licensing, customer accounts, update checks, support, and the Royal Apps community. Those services are separate from the Royal TS/TSX document and credential store.

Royal documents containing sensitive information should be protected with a strong, unique document password. Customers remain responsible for securing endpoints, file-system access, Royal Server installations, backups, exports, service accounts, and networks on which the products operate.

Royal Apps applies security-related engineering practices including peer review, automated builds and tests, relevant manual application testing, dependency monitoring, risk-based remediation, and controlled software releases. The limitations of the current security-assurance program are stated explicitly below.

Data storage and product architecture

Royal TS/TSX use file-based configuration management. Credentials and other objects are stored in Royal documents rather than in a central credential database. See Documents and Files.

Royal Server’s optional Document Store hosts Royal document files on infrastructure operated by the customer. Its configuration database contains Royal Server configuration and authorization information; it is not the credential store. Credentials hosted through Royal Server remain part of the corresponding Royal document. See Royal Server Document Store configuration.

Customers control where local Royal documents and backups are stored and, when Royal Server is used, the server and storage location on which hosted documents reside.

Credential encryption and key management

Documents without a customer-supplied encryption password

If a document is not password-protected, Royal TS/TSX still stores sensitive fields in an encrypted form rather than as readable plaintext. However, because no customer-supplied password is required, this built-in protection should not be considered equivalent to password-based document encryption. Customers should enable document encryption and use a strong, unique password for documents containing credentials or other sensitive information.

Password-protected documents

When document encryption is enabled, sensitive fields are protected using XTS-AES-128 (two 128-bit keys, i.e. 256 bits of key material) derived from the customer-supplied document password using PBKDF2, as specified by RFC 2898. The derived encryption material is created locally when the document is unlocked and is not stored as a reusable account credential.
Sensitive values remain encrypted in persistent document storage and in the application’s data model. They must, however, be decrypted in memory when an authorized operation needs to use them—for example, when initiating a connection or copying a password. Royal Apps does not claim that plaintext can never exist in process memory.

Royal documents also support complete-file encryption. A completely encrypted document can additionally be placed in lockdown mode to restrict operations such as revealing passwords or modifying document contents. See Security, Working with Documents, and the document security settings for more information on this topic.

Royal Server encryption

The Royal Server can apply an additional product-managed AES-256 server-side encryption layer to document files hosted in its Document Store. The Royal Server can also enforce that a hosted document may only be opened through the designated Royal Server, so that a copied document file cannot be opened directly in Royal TS/TSX. See Document Store configuration.

This additional Royal Server encryption layer is product-managed and is not integrated with an external customer KMS or HSM.

BYOK and separation of credentials

Royal TS/TSX and Royal Server do not currently support conventional KMS/HSM-based Bring Your Own Key (BYOK) or Customer-Managed Key (CMK) integration. The customer selects and controls a Royal document password, but we must point out that password-based document encryption is not equivalent to an enterprise CMK/BYOK capability.

Document passwords, and the encryption material derived from them is logically independent of:

  • Royal Apps customer-account passwords.
  • Royal Server authentication credentials.
  • Windows service and worker-account credentials.
  • Credentials stored in Royal documents for accessing managed systems.

Royal Server’s product-managed server-side encryption layer does not provide external KMS separation.

Royal Server security controls

The Royal Server also provides additional customer-managed access boundaries for centrally hosted documents. Depending on the components and settings used, these controls include:

  • TLS-protected communication using a configured server certificate.
  • Authentication based on Windows security mechanisms.
  • Membership in the Royal Server Users and Royal Server Administrators groups for user and administrative operations.
  • Per-document Read and Modify access rules for Windows users and groups, with explicit Grant and Deny rules.
  • Optional Multi Factor Authentication for Document Store and Secure Gateway operations. Supported providers include TOTP, Duo, and YubiKey.
  • Document settings that can require access through Royal Server and enforce encryption or lockdown policies.

See the documentation for Document Store configuration, Document Store access rules, and Multi Factor Authentication for more information on these topics.

Please note that these controls complement, but do not replace, appropriate endpoint, operating-system, file-system, backup, certificate, and network security.

Secure development and dependency management

Royal Apps does not currently claim a formal, independently audited, or certified Secure Software Development Lifecycle (SSDLC). Security practices are nevertheless integrated into the normal development and release process through:

  • Peer review of product changes.
  • Automated builds and tests, together with relevant manual application testing.
  • Automated monitoring and alerts for known vulnerabilities and available updates in third-party and open-source dependencies.
  • Review of security advisories and CVEs for affected versions, exploitability, product exposure, severity, and available vendor remediation.
  • Risk-based remediation, validation, and controlled maintenance or security releases.

Dependency alerts are reviewed at least weekly, whereas critical or actively exploitable issues are handled outside that normal cadence. Relevant fixes are released as soon as implementation and validation permit. This does not mean that every dependency is upgraded every week; updates are evaluated for relevance, compatibility, and regression risk.

Dependency vulnerability monitoring constitutes Software Composition Analysis (SCA) only. It should not be interpreted as a formal Static Application Security Testing (SAST) program.

Royal Apps products incorporate third-party and open-source components. The installed applications include the applicable third-party license notices. Because dependencies change between releases, this article intentionally does not maintain a static component inventory.

Security testing, assessments, and certifications

Royal Apps does not currently claim:

  • A regular independent penetration-testing program.
  • A formal Dynamic Application Security Testing (DAST) program.
  • A formal Static Application Security Testing (SAST) program.
  • A formal, independently audited, or certified SSDLC.
  • ISO 27001 or a comparable third-party product-security certification or attestation.
  • Recent independent security assessment reports or executive summaries that are available for customer distribution.

These limitations do not mean that security is excluded from development. The peer review, testing, dependency monitoring, advisory evaluation, risk-based remediation, and controlled-release practices described above are part of Royal Apps’ normal engineering work. These practices are operational processes and are not presented as independently audited controls.

Logging and auditing

Royal Apps products provide operational and diagnostic logging. These capabilities should not be treated as a compliance-grade, immutable security audit trail.

Royal TS for Windows can record application activity, errors, and diagnostics to an internal in-memory log, log files, and the Windows Event Log. Advanced Serilog configuration supports additional destinations such as Elasticsearch, HTTP, Microsoft SQL Server, Splunk, and Syslog. See Royal TS logging options.

Royal TSX for macOS provides its own platform-specific logging configuration. It can write application logs to local files or to the macOS system log, where entries can be viewed using Console. File logging, its verbosity, and the destination path can be configured under Royal TSX > Settings > Logging. These capabilities are intended primarily for operational diagnostics and troubleshooting. The advanced Serilog destinations described for Royal TS are not available in Royal TSX. See the Royal TSX feature overview.

Royal Server can log operational events and request metadata, including authentication failures, blocked login attempts, and management or administrative requests. Destinations include files, the Windows Event Log, and experimental Syslog support. See Royal Server logging.

There is no dedicated field-level audit record for every credential reveal, copy, use, or modification. Document loads and saves, and some management requests may be logged, but the resulting records do not constitute a complete credential-access audit trail.

Verbose Royal Server request/response logging is intended for troubleshooting. It can significantly affect performance and storage use and may capture other sensitive request content even though known password fields are excluded. It should be enabled only when needed and is not a substitute for security auditing.

Security updates and customer communication

Royal TS/TSX and Royal Server provide optional update checks, and changes are documented in release notes. Customers should enable update notifications or otherwise monitor supported release channels.

When a significant security issue requires customer action, Royal Apps may also publish information through the Royal Apps blog and Royal Apps social channels. Examples of this communication model include the SSH Terrapin remediation notice and the November 2025 Royal Server security advisory.

A person who reports a vulnerability through the support system receives applicable updates through the corresponding support ticket.

Reporting and remediating vulnerabilities

Suspected security vulnerabilities should be reported through the Royal Apps Helpdesk or by email to [email protected]. Reports should include the affected product and version, a description of the issue, reproduction information, and the potential impact when known. Do not include passwords, private keys, or other live credentials.

Royal Apps’ operational remediation workflow is to:

  1. Acknowledge and triage the report.
  2. Reproduce the issue where possible.
  3. Assess severity, exploitability, and product exposure.
  4. Track the remediation work.
  5. Implement and test the fix.
  6. Release the applicable update.
  7. Communicate any required customer action.

Prioritization is risk-based. Royal Apps does not currently publish a contractual remediation SLA or a formal public-disclosure timetable.

Recommended customer security practices

  • Protect every Royal document containing sensitive information with a strong, unique encryption password.
  • Consider complete-file encryption and lockdown policies for higher-risk environments.
  • Restrict access to Royal documents, application data, exports, and backups using operating-system permissions.
  • Keep Royal TS/TSX and Royal Server on current supported maintenance releases.
  • For Royal Server, configure TLS with an appropriate certificate and restrict network access to required systems and users.
  • Configure Windows groups, per-document access rules, and MFA according to the organization’s access-control policy.
  • Use separate, least-privilege Windows service and worker accounts where applicable.
  • Enable suitable operational logging and forward Royal Server logs to the organization’s monitoring platform when required.
  • Protect endpoints and backups and test recovery procedures as part of the organization’s broader security program.

Vendor and procurement information

Royal TS, Royal TSX, and Royal Server are developed by Royal Apps GmbH. Current company and legal information is available on the Royal Apps company page.

Depending on the purchasing route, the vendor of record may be Royal Apps’ authorized commerce provider or a reseller. Customers should use the current Royal Apps purchasing page, their quotation or invoice, or their chosen reseller’s details when completing procurement records. Reseller and sales questions can be submitted through the Royal Apps Helpdesk.

Document maintenance

Royal Apps reviews this article at least annually and when a stable major product is released, or when an encryption design, a material security process, a certification status, a vulnerability-reporting process, or a logging capability changes.