Privacy Policy

Information We Collect

1.1 Website & Account Information

• Account Information: Email address, password (hashed with PBKDF2-SHA512, 600,000 iterations per OWASP guidance), first and last name, and any profile details you provide when creating an account.
• Two-Factor Authentication: If you enable 2FA, the TOTP secret is stored alongside your account so the portal can verify codes from your authenticator app.
• Transaction Data: Purchase history, subscription status, and a Stripe customer/subscription identifier. Card numbers and full billing details are held by Stripe — we never see or store them.
• Support Communications: Support ticket content, attachments, and any email correspondence you send us.
• Server Access Logs: Standard HTTP access logs (IP, user-agent, request path, timestamp) generated by the web server for security and abuse prevention.
• Time Zone: When you are signed in, your browser reports the IANA time-zone name it is set to (for example America/Toronto) and we store it on your account. It is used for one thing: displaying dates and times in your own local time rather than in UTC. It is detected from your browser rather than asked for, so it is disclosed here; you can see and change the stored value on your profile page.

1.2 PNT-RMMS Desktop Client Data

When you install and use the PNT-RMMS Agent, the following data is reported to our servers:

• Hardware Inventory: Computer hostname, system manufacturer, model, serial number, CPU name and core count, total RAM, and per-drive storage details.
• OS & Runtime State: Windows edition / build / architecture, last boot time, time-zone, domain-join status, current CPU and memory utilization, free disk space, and the agent's version number.
• Network Data: Primary network adapter MAC address (used as a hardware fingerprint for license deduplication) and the public IP address the device most recently reported from. Local IPs and other interface addresses are not reported.
• Agent Metadata: Encrypted device token (DPAPI-protected on disk under a per-machine key) and license-validation state.
• Diagnostic Logs: Logs from the Agent are forwarded to the portal for centralized troubleshooting — Warning level and above, plus a small number of named categories that forward at Information level for diagnostic purposes. These logs are about the operation of the software rather than about the person using the device, and we redact credential-shaped values from them automatically. They are not, however, guaranteed to be free of personal data: an error raised while handling a file records the path involved, which on Windows normally contains the account name and may contain a document name; an error raised while carrying out an operator's instruction records that operator's email address; and a line that identifies the device an event came from records that device's hostname, which often names the person who uses the machine. We do not use these logs for any purpose other than diagnosing faults, and they are subject to the retention period in section 4. Automatic crash diagnostics are a separate, larger collection — see Automatic crash diagnostics in section 8.
• Remote Session Summaries (v1.4.17+): At the end of each remote-control session the Agent posts a summary containing start/end timestamps, the connection path that won (LAN-direct, direct over WAN, or relay), bytes transmitted on each path, and the public IP of the operator. No screen content or input is stored — only the path and byte totals.

1.3 Remote Access Session Data

When a remote-control session is initiated, the following is captured:

• Session Metadata: Start/end timestamps, the operator's identity, the path that connected the session (LAN-direct, direct over WAN, or relay), and per-session bytes transmitted.
• Screen Content: Screen frames are transmitted in real time to the connected operator's browser. All transit is encrypted — direct WebRTC connections use DTLS-SRTP, and relayed connections use TLS over WSS. Screen content is not stored on our servers; only the byte counts and connection path are persisted. Relayed sessions are not end-to-end encrypted — see Relay fallback in section 1.4 below for exactly where the encryption terminates.
• Audit Logs: Authentication events (account login, MFA enrollment, role changes), subscription changes, and device activations are logged on the portal for security and compliance review.

1.4 Peer-to-Peer Connection Data

PNT-RMMS prefers direct connections over WebRTC and only falls back to relay when direct fails:

• STUN candidate gathering: Your device contacts our self-hosted STUN server (stun:rmms.pronovatech.com:3478), with Cloudflare and Google STUN as fallbacks if our server is unreachable. STUN reveals the device's public IP and port to itself; no session content flows over STUN.
• mDNS resolution (v1.4.17+): When the operator's browser is on the same local network as the device, the Agent resolves browser-emitted .local hostnames via standard multicast DNS (UDP 5353) so the connection can stay on the LAN. mDNS queries never leave the local broadcast domain.
• Relay fallback: When a direct connection cannot be established, sessions traverse our PNT-operated relay servers over TLS-encrypted WebSockets. We do not operate or use third-party TURN servers. Relayed traffic is forwarded in flight and is not recorded.
• Where encryption terminates on the relay path: A relayed session is not end-to-end encrypted between the managed device and the operator's browser. TLS terminates at the relay, which is a host operated by Pro Nova Technologies Inc. The relay decrypts each message it receives, reads the session's control messages, and re-encrypts to the other party over its own separate TLS connection. It does this because it has to: the relay is what enforces that a connected party can only act inside the session it was actually authorized for, and it does that by reading and overwriting the session identifier and the operator's email address on every control message rather than trusting what the sender put there. A consequence of that design is that, while a relayed session is in progress, session content — including screen frames — exists in the clear in the relay's memory. It is forwarded and discarded: nothing is written to disk, recorded, or retained on the relay. If you require that no PNT-operated host is able to observe session content, use a direct (peer-to-peer) connection, which does not traverse a relay at all and is encrypted end-to-end with DTLS-SRTP. The connection path actually used for each session is recorded in the session summary and is visible to you on the portal.

1.5 RMMS Portal Data

If you use the portal to manage your company and devices, we also store:

• Company name, address (if provided), and organizational structure (locations, device groups).
• Team-member invitations, role assignments (Owner / Member / Viewer), and join history.
• Per-device assignment metadata (which user activated which device, when).

1.6 Browser Notifications & the Service Worker

Browser notifications are off unless you turn them on from Notification Settings in the portal. If you do:

• A service worker is installed. Your browser registers a small script (/sw.js) that remains after you close the tab, so a notification can appear when the portal is not open. It displays notifications we send, opens the portal at the relevant page when one is clicked, and re-registers your subscription if your browser rotates it. It does not cache pages or record your activity.
• We store a push subscription. Your browser issues an address at its maker's push service, together with a public key and an authentication secret that it generates itself and uses to decrypt what we send. We store those against your account so we can reach that browser, along with the browser's user-agent string, which is recorded at the moment you subscribe so that an operator diagnosing undelivered notifications can tell one of your subscribed browsers from another. We delete all of it when you disable notifications or when the push service tells us the address is dead. One stored subscription is one browser profile on one device.
• The message passes through a third party. Delivery is performed by a push service run by your browser's maker — see Browser Push Services in section 3. The notification — its heading and text, which for a device alert names the device concerned — is encrypted before it leaves us and can be decrypted only by the browser that subscribed, so the push service handles it without being able to read it and sees only that a message was sent to an address it issued.

How We Use Your Information

• To operate, maintain, and improve our Site and Services.
• To process transactions, manage subscriptions, and enforce device licenses.
• To provide remote monitoring, management, and technical support through PNT-RMMS.
• To authenticate users and devices, and validate software licenses.
• To communicate with you, respond to support tickets, and provide customer service.
• To detect and prevent fraud, abuse, and security threats.
• To analyze website and service usage patterns and improve performance (using privacy-preserving analytics).
• To send transactional communications (order confirmations, license notifications, MFA codes).
• To maintain audit trails for compliance and security purposes.
• To deliver automatic software updates for PNT-RMMS.

Sharing Your Information

We do not sell your personal information. We may share information with:

The same recipients are set out as a consolidated sub-processor list, with what each one receives, in section 2 of our Security & Disclosure page.

• Payment Processor (Stripe): For secure payment processing. We do not store full credit card numbers.
• Email Delivery Provider: Transactional email — account confirmations, password resets, company and device invitations, ticket notifications and notification digests — is delivered through a third-party SMTP provider. It handles your email address and the content of those messages in order to deliver them. The provider is configured per deployment rather than fixed in the product, so it is not named here; ask us if you need its identity.
• Authorized Administrators: PNT-RMMS remote access sessions allow authorized administrators to view and interact with devices. Access is controlled by permissions, support agreements, and audit logging.
• Company Members: If you belong to an RMMS company, other authorized members may see device names, online status, and permission levels.
• Infrastructure Providers: Hosting providers who assist in delivering our Services, subject to confidentiality agreements.
• Content Delivery Networks (Google Fonts and jsDelivr): Portal pages load web fonts from Google and an icon set from jsDelivr. Your browser fetches those files directly from those networks, which discloses your IP address and browser version to them on each page load. We ask your browser not to send them the page address, they set no cookies, and we send them nothing about your account, devices or activity. See our Cookie Policy for the full description.
• Browser Push Services (Google, Mozilla, Microsoft, Apple): Only if you enable browser notifications. Web push is delivered by a service run by your browser's maker — Google for Chrome and Edge, Mozilla for Firefox, Microsoft for Windows notification delivery, Apple for Safari — and your browser chooses which one; we cannot. That service receives the address it issued for your browser, the timing of each message, how long we asked it to hold the message, and a contact address for us that identifies Pro Nova rather than you. It also carries the notification itself — but it cannot read it: the heading and text are encrypted with keys your browser generated and never gave to the push service, so only that browser can open them. Nothing else about your account, your devices or your activity is attached. Disabling browser notifications ends this entirely. See our Cookie Policy for the full description.
• Legal Requirements: When required by law, regulation, legal process, or government request.

Data Security

We implement reasonable technical and organizational security measures, including:

• TLS in transit. All portal HTTP traffic, all relay WebSocket traffic, and all device-to-portal heartbeats use HTTPS / WSS with TLS. On the relay path that TLS terminates at a PNT-operated relay host rather than running end-to-end — see section 1.4 for what that means in practice.
• WebRTC DTLS-SRTP for direct sessions. When a session establishes a direct peer-to-peer connection, the data channel is protected by DTLS-SRTP — separate from our relay's TLS.
• Code-signed installers. All shipped installers and binaries are Authenticode-signed by Pro Nova Technologies Inc. using an EV code-signing certificate held on a hardware token, with RFC-3161 timestamping.
• DPAPI-encrypted local secrets. The device token cached on a managed device is encrypted with Windows DPAPI under a per-machine key, with file ACLs restricting read access to SYSTEM and Administrators.
• AES-256-GCM at rest for portal secrets. Sensitive portal-side configuration values (such as SMTP credentials and integration API keys) stored in the SecureSettings table are encrypted with AES-256-GCM before being written to the database.
• Strong password hashing. Customer account passwords are hashed with PBKDF2-SHA512 at 600,000 iterations (per current OWASP guidance).
• Two-factor authentication. Optional TOTP-based 2FA (compatible with Google Authenticator, Authy, 1Password, etc.) is available for any portal account, with one-time recovery codes.
• Authenticated heartbeats. Every device-to-portal request carries an X-Device-Token the device received at activation; tokens are tied to the device's identity and its company's subscription state.
• Rate limiting and lockout. Brute-force and abuse-prevention protections are applied to authentication endpoints.

No system on the public internet is perfectly secure. We work to keep your data safe but cannot promise absolute security.

Reporting a vulnerability. If you have found a security flaw in the portal, the agent, the relay or the Pro Console, please tell us — see our Security & Disclosure page for where to send it and what we commit to doing with it. A machine-readable copy of the contact is published at /.well-known/security.txt.

If something does go wrong. Our GDPR page sets out what we owe to supervisory authorities and to affected individuals after a personal-data breach. What we commit to telling you, as our customer — when, through what channel, and what the notice will contain — is set out in section 3 of the Security & Disclosure page.

Data Retention

We retain personal information only as long as needed to operate the service or as required by law:

• Account Data: Retained until you delete your account.
• Transaction Records: 7 years (legal/tax requirement).
• Support Tickets: 3 years after resolution.
• RMMS Device Inventory: Retained while the device is registered to an active subscription. If your subscription lapses, device tokens are preserved for 90 days so renewal automatically restores the fleet; manually-deactivated devices retain their tokens for 180 days. After those windows, tokens are wiped and the device must be re-activated to be used again.
• Remote Session Summaries: 12 months on the portal, then automatically pruned. Each summary contains only path, byte counts, and timestamps — no screen content.
• Audit Logs: 12 months by default.
• Diagnostic Logs (forwarded from agents): 90 days on the portal.
• Stripe Webhook Records: 90 days, then automatically purged.

Your Data Rights

Depending on your location (e.g., GDPR, CCPA), you may have the following rights:

• Access: Request access to the personal data we hold about you.
• Correction: Request correction of inaccurate data.
• Deletion: Request that we delete your personal data.
• Opt-Out: Opt-out of marketing communications or the sale/sharing of data.

To exercise these rights, please contact us at support@pronovatech.com.

Children's Privacy

Our Services are not intended for children under 16 years of age. We do not knowingly collect personal information from children under 16. If we learn we have collected information from a child under 16, we will promptly delete it.

PNT-RMMS Specific Disclosures

The PNT-RMMS Agent operates with the following specific behaviors you should be aware of:

• Background operation. The Agent installs a Windows Service that starts at boot and runs continuously. The companion tray app launches in active user sessions to surface activation, status, and consent prompts.
• What an operator can do during a session. View the screen, send mouse and keyboard input, browse the file system, transfer files in either direction, read and set the clipboard, redirect print jobs to the operator's local printer, restart or shut the device down, and chat. Where the device's company has enabled it, an operator can also execute arbitrary commands at SYSTEM privilege — the highest level Windows provides — which is general enough to read or change any file and to alter Windows services, the registry and security settings. Command execution, file transfer, power control and configuration changes are each recorded with the operator's identity and are visible to the company that owns the device. The Agent does not capture the webcam and does not record sessions to storage.
• Cross-session input. The Service can forward input to the Windows login screen, locked workstations, and UAC consent prompts so an operator can recover a frozen sign-in or approve elevation. This capability requires two installer-time toggles (UAC consent prompts and Skip Ctrl+Alt+Del at sign-in) and is off by default.
• Connection-mode setting. Each device runs in either Automatic mode (operators with permission connect without on-device approval) or User-Approved mode (a prompt appears on the device and a local user must accept before the operator gets in). Automatic is the default. The mode is held on the device and set there, through the PNT RMMS Agent, by someone with administrative rights to that device. The portal displays the mode each device reports; it does not currently set it. User-Approved mode also cannot obtain approval when nobody is signed in, so a connection to the sign-in screen may proceed without a prompt.
• Auto-updates. The Agent periodically checks the portal for new releases and can install them automatically. Downloaded installers are verified by hash against the portal's release manifest before they run, and only Authenticode-signed installers from Pro Nova Technologies Inc. will execute.
• Public IP handling. The most-recently-reported public IP for a device is stored on the portal in plain form so operators can see roughly where a device is and confirm path selection. It is visible only to authenticated members of that company and to PNT support staff.
• Automatic crash diagnostics. If the Agent's Windows Service starts 4 times within a 10-minute window, it treats that as a crash loop and automatically builds and uploads a diagnostic bundle to the portal, with no prompt and no user action. The bundle contains the Agent's own log files together with excerpts of the Windows Event Log from the device. These are raw diagnostic artefacts rather than filtered telemetry, so they can contain machine names, Windows user names, file paths and application error text from the device. This behaviour is on by default, and is rate-limited to at most one automatic bundle per hour. It can be turned off per device by setting CrashLoopAutoReport:Enabled to false in the Agent's configuration; doing so does not affect the "Report Issue" button in the tray app, which only ever uploads when you press it.
• What is NOT collected. Audio of any kind — neither microphone input nor the sound the device is playing — webcam video, keystroke logging, and browser history. Screen content during a session is forwarded live and is never stored by us. Two qualifications, so this list is not read more broadly than it holds: an operator can browse and retrieve files during a session, which is a deliberate capability rather than background collection; and the Windows Event Log excerpts included in an automatic crash diagnostic bundle are produced by the operating system and can reference applications other than ours.

Updates to This Policy

We may update this Privacy Policy from time to time. The "Effective Date" at the top of this page will be updated to reflect any changes.

Contact Us

If you have questions about this Privacy Policy, please contact us: