Certificate-backed agent identity
Enrolled agents use client certificate identity and pinned server trust material instead of a shared fleet password. Agent trust is designed to survive planned rotation without turning rotation into a fleet outage.
Security controls for the hosted TvRMM SaaS.
TvRMM is designed around certificate-backed agents, pinned trust material, session-authenticated portal routes, role-gated actions, tenant and organization boundaries, remote-access preflight gates, and customer-visible support access.
This page describes controls represented in the hosted SaaS and TvRMM operating model. It is not a compliance certification or a substitute for customer due diligence.
Controls enforced today.
TvRMM security is a chain from endpoint identity through human authorization, tenant scoping, lifecycle cleanup, browser controls, and customer exit rights.
Session-protected portal
Human portal routes require an authenticated session. Regression coverage keeps human-facing API surfaces inside that session boundary, while explicitly public and agent endpoints remain separate.
CSRF and origin protection
Cookie-authenticated mutations are guarded by central unsafe-method protection across portal and session-authenticated API routes, using same-origin request evidence and X-CSRF-Token support for JavaScript calls.
Auth rate limiting
Login, forgot-password, magic-link, signup-code, and OAuth signup-start paths are rate limited by network source and account or tenant context.
Role-gated mutations
Operational actions are gated by role. Viewer, operator, admin, owner, and platform-admin authority are separated so day-to-day work does not require the highest account privilege.
Tenant and organization scoping
Hosted SaaS requests are scoped to the tenant and organization authority available to the signed-in user. Lists, settings, actions, exports, and policy surfaces are designed around that customer context.
Soft-delete and offboarding controls
Endpoint deletion hides active rows, queues uninstall, revokes client certificates, and keeps cleanup paths available during wind-down instead of treating delete as only a UI change.
Remote access preflight gates
Remote control is blocked until policy, endpoint state, helper state, relay state, licensing, clipboard, and file-transfer requirements are satisfied.
Visible support model
Support access requires customer approval and is scoped, time-limited, and logged. The model is explicit support entry, not silent vendor access.
Public security posture
The public site ships security headers, a security.txt disclosure path, and CSP validation in the build and deploy process.
Control matrix.
The table below connects each security promise to its customer-facing effect in the hosted SaaS.
| Area | Control | Customer effect |
|---|---|---|
| Endpoint enrollment | Portal-generated enrollment commands bind the endpoint into the selected customer context. | Reduces accidental cross-customer enrollment and avoids static shared bootstrap secrets. |
| Agent transport | Agent communication uses TLS trust material, client identity, and SPKI pinning checks in the agent trust path. | Pinning blocks an arbitrary certificate from impersonating the SaaS control plane. |
| Agent certificate profile | Client certificates are issued for client authentication, while server certificates are kept out of client-auth usage. | Limits certificate confusion between agent identity and server identity. |
| Trust refresh | Trust bundle refresh and CA self-heal paths are pinned to expected signing or transport keys. | Allows planned trust updates without accepting unpinned trust material. |
| Deleted or revoked agents | Deleted, revoked, or unknown endpoint identity is handled as a stop condition for normal command authority. | A retired endpoint no longer receives routine management instructions. |
| Human access | Portal and human API routes use session middleware and action-level role checks. | A signed-in user still needs the right role before changing customer state. |
| CSRF defense | Unsafe cookie-authenticated methods require same-origin evidence or a valid CSRF token appropriate to the request path. | Session cookies alone are not enough to authorize a browser-originated mutation. |
| Abuse throttling | Authentication and signup entry points use per-IP plus per-account or per-tenant rate-limit buckets. | Credential stuffing, mailbox flooding, and signup-code guessing have request-level friction. |
| Tenant boundary | Handlers and policy surfaces use organization visibility checks and deleted-row filters. | Users can see and mutate only active resources in their permitted customer scope. |
| Route regression tests | Human-facing API route inventory tests keep new /api/v1 routes inside the session-auth boundary. | The test fails when a new portal API surface bypasses authentication. |
| Active-org regression tests | DB-backed tests cover policy targeting and script-variable organization scopes. | Deleted or inactive organizations stay out of mutation paths as the policy surface grows. |
| Operational secrets | Hosted deployment secrets are pulled from OVH Secret Manager and GitHub environment secrets, with Azure removed from the active hosted path. | Production secret access is centralized around the current OVH-based SaaS operating model. |
| Marketing and help site | CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, and security.txt are validated before public deploy. | The public surface has browser-side guardrails and a published disclosure contact. |
| Customer exit | Export, uninstall, cleanup, retention, billing, and subprocessors pages are part of the security model. | Security includes safe offboarding, not only login and encryption. |
Endpoint lifecycle trust model.
Endpoint security starts before the first heartbeat and continues through updates, deletion, certificate revocation, and cleanup.
Enroll
The endpoint starts from a current portal-generated bootstrap command for the selected platform and customer context.
Authenticate
The agent presents enrolled identity and validates server trust material before normal communication.
Operate
Heartbeat, inventory, audit, patching, scripts, terminal, reboot, and remote desktop controls are exposed only where the platform and customer policy allow them.
Update
Released agent versions are verified by later heartbeat evidence from the new binary, so the portal can distinguish a queued update from a completed one.
Retire
Deletion queues uninstall, revokes endpoint certificate authority, hides active UI rows, and preserves offboarding expectations.
Human authority is layered.
TvRMM does not treat a successful login as permission to do everything. Session authentication establishes who the user is; role gates and tenant scope determine what they can do.
| Role layer | Security intent |
|---|---|
| Viewer | Read-oriented access for inspection and reporting. |
| Operator | Day-to-day operational action authority where customer policy allows it. |
| Admin | Configuration and organization management authority. |
| Owner | Tenant-level ownership authority for billing, membership, and high-impact customer settings. |
| Platform admin | Separated service-side authority for platform operations, not a substitute for customer-visible support access. |
Remote access is gated before control.
Remote access requirements are visible before a session starts. A blocked state identifies the missing requirement.
| Gate | Customer-facing meaning |
|---|---|
| Policy enabled | Remote access must be allowed by the applicable customer policy. |
| Endpoint eligible | The endpoint must be a real supported direct agent, online, licensed, and allowed by tenant settings. |
| Helper ready | The local helper must exist and report the expected capability state for that platform. |
| Relay connected | The session relay must be available before remote control is attempted. |
| Clipboard and file transfer | Clipboard and transfer-folder behavior are separately gated so data movement is not assumed. |
| No inbound customer port | TvRMM remote access does not require an exposed VNC or RDP port on the customer endpoint. |
Public surface protections.
The security posture includes the marketing and help surfaces customers inspect before trusting the SaaS.
Content Security Policy
The public site build hashes inline scripts and refuses deploy paths that still allow unsafe inline script execution. The portal enforces CSP on auth and signup pages while broader portal pages continue to emit report-only CSP during the staged authenticated-surface rollout.
Transport and framing headers
HSTS, frame denial, strict referrer handling, permissions policy, object blocking, and base-uri restrictions are part of the public-site header set.
Security disclosure
TvRMM publishes security.txt and a security disclosure page so researchers and customers have a clear reporting route.
Compliance readiness
The public compliance readiness page presents the self-attested SOC 2-aligned program, roadmap, published evidence index, backup limitations, and subprocessor summary without presenting them as an audit report.
Public policy set
Terms, privacy, DPA, acceptable use, billing, retention, support, subprocessors, cookies, and security disclosure pages make expectations reviewable before signup.
Additional shipped hardening.
These controls close common SaaS failure modes around cookie sessions, auth abuse, browser policy drift, route coverage, and active-organization scoping.
| Control | Security effect |
|---|---|
| CSRF and origin guard | Unsafe cookie-authenticated methods on /ui/** and session-authenticated /api/v1/** routes require same-origin request evidence or a valid CSRF token. JavaScript calls use X-CSRF-Token. |
| Auth and signup throttles | Login, forgot-password, magic-link, signup-code check, and OAuth signup-start routes apply per-IP plus per-email or per-tenant rate limits. |
| Portal CSP enforcement | Portal CSP is enforced on auth and signup pages with inline script execution removed from the enforced policy; wider portal pages emit report-only CSP while the authenticated surface is staged forward. |
| Human API inventory test | A regression test inventories human-facing /api/v1 routes so new routes cannot accidentally ship outside auth middleware. |
| Active organization scope tests | DB-backed tests cover policy targeting and script-variable organization scopes so deleted or inactive organizations cannot be used as mutation targets. |
Operating commitments.
These principles keep the implementation aligned with the public promises as the product grows.
Least useful authority
Expose the authority needed for the workflow, then log and scope it.
No silent tenant entry
Support access is customer-approved and visible.
Fail closed on identity problems
Revoked, deleted, or unknown endpoint identity does not retain normal command authority.
Separate inventory from control
Host-reported guests can be inventory-only until a real in-guest agent exists.
Make exits safe
Security posture includes export, uninstall, cleanup, and wind-down behavior.
Keep support states explicit
Remote, package, appliance, and platform claims show their gates and support states instead of hiding workflow requirements.