Security

Security and architecture

Monitoring data is some of the most sensitive data a company holds. Here is exactly how Cleanwork by PTM protects it, mechanism by mechanism, and what stays your responsibility.

The short version

Cleanwork by PTM is self-hosted. The server, the database and every screenshot live on infrastructure you control, with access controlled by your organisation. Optional managed hosting or support access has separate operational arrangements. The customer portal separately holds your account, billing and activation metadata. It does not receive employee monitoring records. Issued activation keys are validated offline by the self-hosted server. The rest of this page lists what the software actually does, with the mechanism named in each case so you can verify it in the code you run.

Customer portal security

  • Account verification requires access to the mailbox and confirmation of the password used to complete setup. Recovery and verification links expire after 30 minutes and are consumed atomically.
  • Passwords use bcrypt with a 12-character minimum and a 72-byte UTF-8 maximum. Sessions use HttpOnly, SameSite cookies, with Secure enabled on the HTTPS deployment. Password resets and sign-out revoke outstanding sessions.
  • Browser mutations require the configured origin. Account, recovery, checkout and activation routes have rate limits. Account responses are marked no-store.
  • Payment access is granted from verified provider webhooks, never from a checkout redirect. Account ownership and deployment limits are checked before activation.
  • The licensing database contains account and billing metadata. Its host and backups require access controls and storage encryption; screenshot encryption in the self-hosted product does not encrypt the licensing database automatically.
  • Single-use setup codes are emailed over a TLS-protected SMTP connection. The server exchanges a code for a signed licence over HTTPS. Connected licences receive signed revocations at check-in; a permanent offline licence file cannot be remotely withdrawn.

Data at rest

  • AES-256-GCM for screenshots, captured URLs and window titles, using a DATA_ENCRYPTION_KEY generated and persisted by the server unless your operator supplies one; you must preserve it with your recovery backups. GCM is authenticated, so tampering is detected rather than silently accepted.
  • Screenshots are compressed to WebP before encryption, which keeps the encrypted volume small.
  • Passwords are hashed with bcrypt. They are never stored or logged in a recoverable form.
  • Screenshot cleanup is eventual: the server removes images older than SCREENSHOT_RETENTION_DAYS, which defaults to 90 days and is yours to change. Cleanup failures or backlog can delay deletion. Activity, backups and object versions need separate policies; audit records have their own TTL.
  • Optional S3-compatible storage (AWS S3, Cloudflare R2 and similar) is configured by an administrator from the dashboard. Those credentials are encrypted server-side and are not returned to the browser after saving.

Data in transit and session handling

  • Dashboard sessions ride in HttpOnly cookies, so a cross-site scripting bug cannot read the session token from JavaScript.
  • Login is rate limited. Password verification uses bcrypt; this reduces brute-force risk but does not make the entire network request constant-time.
  • The server sets a strict Content-Security-Policy plus HSTS, nosniff and clickjacking protections via Helmet.
  • Plain HTTP is supported for localhost development. Packaged agents require HTTPS for a non-local server, including LAN deployments. Put TLS termination in front of the server. The manual covers this in Deploy the backend.

The desktop agent

  • The agent uses Electron safeStorage to protect its API token where an OS encryption backend is available. Windows, macOS and Linux use different backends; Linux depends on the desktop keyring configuration. Validate credential persistence and the backend on each supported desktop image.
  • Employees register with just their work email. Each registration appears in the dashboard and is recorded in the audit trail, and an administrator can block or remove anyone at any time; a blocked employee cannot register again. The plan's employee limit caps how many can join, registration is rate limited, and no shared secret is baked into the installer.
  • The agent is visible. It runs in the system tray with a status icon, so the person using the machine can always tell it is there. That is a deliberate product decision, not a configuration option.
  • Outside an employee's configured monitoring hours the agent fully pauses and reports Offline.

Licence verification and connectivity

Licence keys are signed with Ed25519 and verified locally against a public key embedded in the server. Connected installations check in at startup and hourly, sending the signed key, Install ID and a random process ID, without employee monitoring records. Each signed licence allows up to seven days without a successful refresh, or until its trial or subscription ends if earlier. After that deadline, employee data access is locked until a valid refresh arrives. Purchased perpetual licences can instead use a signed permanent offline file, with no periodic connection requirement; server replacement requires PTM support. Portal accounts, payments and email use external services and retain their own metadata.

What we cannot see

In a self-hosted deployment, employee monitoring records remain on your infrastructure and any screenshot storage you configure. The licensing service does not receive those records. PTM separately holds portal account, billing, Install ID and activation-delivery metadata, plus support correspondence. If PTM manages hosting or you grant support access, agree on access and data-handling responsibilities for that service. That is covered in the privacy policy.

What is still your responsibility

Self-hosting moves real duties to you, and it would be misleading to imply otherwise.

  • Keep DATA_ENCRYPTION_KEY backed up somewhere safe. Lose it and the encrypted screenshots are unrecoverable, by design.
  • Put TLS in front of the server for employee connections, including inside your own network.
  • Patch the host, restrict who can reach the dashboard, and back up both database and uploads volumes, encryption secrets, configuration and any external screenshot objects.
  • Tell your employees what is collected and why, and get whatever consent your jurisdiction requires.

Reporting a vulnerability

If you find a security issue, email hello@ptmsoftware.live with enough detail to reproduce it. Please give us a reasonable window to ship a fix before disclosing publicly. We will confirm receipt, tell you our assessment, and credit you if you would like that.