Security & Disclosure

Reporting a Vulnerability

Email support@pronovatech.com with “Security” in the subject line. That mailbox is monitored, and the subject line is what routes a report out of the general support queue.

A machine-readable copy of this contact is published at /.well-known/security.txt in the format defined by RFC 9116.

What to include. A report we can reproduce is worth far more than a scanner result:

• The component and version — portal, agent, service, relay, or Pro Console — and where you found it.
• Steps to reproduce, and what you observed versus what you expected.
• What an attacker gains: whose data, which devices, what privilege.
• Any proof-of-concept, log excerpt or capture that shows the behaviour.

What we ask of you while you are testing:

• Test only against accounts and devices you own or are explicitly authorised to test. Do not access, modify or retain another customer's data, and do not connect to a device you were not given.
• Do not run denial-of-service, spam or high-volume automated traffic against the portal or the relays.
• Do not use social engineering or physical intrusion against our staff or customers.
• Give us a reasonable opportunity to fix the issue before you publish it, and tell us the date you intend to publish so we are not surprised by it.

What we commit to. We will acknowledge every report sent to the address above, we will tell you whether we consider it a vulnerability and why, and we will tell you when a fix has shipped. If we disagree with your assessment we will say so and give our reasoning rather than going quiet.

We do not publish a response-time target. That is a deliberate omission rather than an oversight: we would rather state no figure than one we have not committed to internally. If timing matters to your disclosure schedule, say so in your first email and we will agree dates with you directly.

There is no bug bounty. We do not currently pay for vulnerability reports, and there is no reward programme to enrol in. We will credit you by name in the release notes for the fix if you want that, and will leave you out of them if you do not.

What this page is not. It is not a licence to test, and it is not a legal safe harbour — we are not in a position to bind third parties whose systems your testing might touch, including the sub-processors listed in section 2. It is a statement that a good-faith report made under the conditions above will be treated as a good-faith report.

Sub-processors

These are the third parties that receive customer or end-user data, or that a browser or managed device contacts on our behalf, in the course of running PNT RMMS. The list is derived from what the product actually calls out to, not from a template.

• Stripe, Inc. — payment and subscription processing. Receives your billing name and email address, the card details you enter (which are typed directly into Stripe's own fields and never pass through our servers), and your subscription records. Applies only if you hold a paid subscription.
• Outbound email relay (SMTP provider — not named here). Delivers every transactional email we send: account confirmations, password resets, company and device invitations, ticket notifications and notification digests. It handles the recipient address and the full content of those messages. The provider is configured per deployment rather than fixed in the product, so this page does not name one. If you need the current provider's identity for your own transfer assessment, ask us and we will tell you.
• Browser push services — Google, Mozilla, Microsoft and Apple. Deliver browser notifications, and only if you turn notifications on. Which one is used is chosen by your browser, not by us. Each receives the address it issued for your browser, the timing of each message and how long we asked it to hold one, and the notification itself — which it cannot read, because it is encrypted with keys your browser generated and never shared. Fully described in section 1.6 of our Privacy Policy.
• Google (Fonts) and jsDelivr. Serve the web fonts and icon set used on portal pages. Your browser fetches those files directly, which discloses your IP address and browser version to them on each page load. They set no cookies and receive nothing about your account, devices or activity. Fully described in our Cookie Policy.
• Cloudflare and Google (public STUN servers). Used as fallbacks during connection setup when our own STUN server is unreachable, by the operator's browser, by the managed device and by the Pro Console alike. A STUN server sees a binding request that reveals the public IP address and port of whoever sent it, and nothing else — no session content and no account data ever travels over STUN. We do not operate or use third-party TURN servers, so no third party ever relays session traffic.
• Infrastructure and hosting provider (not named here). Operates the servers running the portal, the PostgreSQL database and the PNT relay hosts. Everything described in our Privacy Policy as stored by us is stored on infrastructure it provides. As with the email relay, ask us if you need the provider's identity and region for a transfer assessment.

Relay servers are operated by Pro Nova Technologies Inc. rather than by a third party, but a relayed session is not end-to-end encrypted — TLS terminates at the relay, which means session content, including screen frames, exists in the clear in that relay's memory while the session runs. That is a deliberate design property with a stated reason, and it is set out in full in section 1.4 of our Privacy Policy. Read it before assuming a relayed session is opaque to us.

We do not currently publish a standard Data Processing Agreement on this site. If your organisation requires one, contact us.

Notifying You of a Security Incident

Our GDPR page sets out what we owe to supervisory authorities and to individuals whose data is affected. This section is the commitment we make to you, our customer, which is a different obligation and was previously unstated.

If we confirm a security incident that has compromised, or that we have reason to believe has compromised, personal data we hold on your behalf, we will notify you without undue delay after confirming it.

We have deliberately not published a fixed number of hours for that notice. We would rather hold ourselves to a standard we can meet every time than to a figure we have not measured; if your own contractual position needs a specific hour count, raise it with us rather than reading one into the sentence above.

How we will reach you. By email, to the address on the affected account and to the owners of the affected company. Keeping a monitored address on your account is what makes this work — we have no other channel that reaches you when the portal itself may be the thing that is compromised.

What the notice will contain, to the extent we know it at the time and updated as we learn more:

• What happened, and when we became aware of it.
• Which categories of data and roughly how many records or devices are involved.
• The likely consequences, stated honestly rather than minimised.
• What we have done and are doing about it, and anything you need to do — for example rotating device tokens or forcing password resets.
• A contact who can answer follow-up questions.

We will send you an initial notice on the facts we have rather than waiting for a complete picture. A slow, complete notice is worse than a fast, partial one that is honest about being partial.

Availability — No Uptime Commitment

PNT RMMS Basic is offered without an availability commitment. We do not publish an uptime target, we do not offer service credits, and there is no service-level agreement attached to the current tier. Section 10 of our Terms of Service already provides the Services “as is” and “as available” with no warranty that they will be uninterrupted; this section states the same position affirmatively so it does not have to be inferred from a disclaimer.

We do not currently operate a public status page. Outages are communicated through support.

We work to keep the service up and we treat downtime as a fault to be fixed, but that is a description of how we operate rather than a number you can hold us to. If your deployment requires a contractual availability commitment, that would be a separate agreement — section 9 of the Terms already contemplates arrangements outside the standard tier. Contact us before you rely on one.

Contact