Security

1. Where we actually stand

We will say so here when that changes, and we will name the auditor and the scope rather than just the badge.

2. How the connection to your plant works

The design choice with the largest security consequence is the direction of the connection.

• A small gateway sits on your network and connects outbound to Sentrel. We never connect inbound to your plant.
• No inbound firewall rule, no port forwarding and no static IP address is needed on your side.
• The gateway reads the equipment you point it at. It does not scan your network.
• Credentials for your equipment, including OPC-UA client certificates, stay on the gateway. The platform stores only the map of which reading goes where.
• Control commands, where enabled, are opt-in per device rather than available by default.

3. Encryption

• All web and API traffic is served over HTTPS with TLS.
• Device connections are secured with TLS, which is what every production deployment should use. Anything carrying a credential across a network you do not control must be encrypted.
• Passwords are stored only as salted, one-way hashes produced by a deliberately slow password-hashing function. They are never stored, logged or transmitted in readable form, and cannot be recovered, only reset.
• API keys are shown once at creation and stored only as a prefix plus a hash afterwards. If a key is lost it has to be reissued, because we genuinely cannot show it to you again.

4. Access control and tenant isolation

• Every workspace is isolated. Queries are scoped to the organization, and no interface allows one customer to reach another's data.
• Access inside a workspace is governed by roles, per-module access and per-capability permissions that an administrator configures.
• Sessions are carried by a signed token in a cookie that JavaScript cannot read, restricted to same-site requests, and expiring after seven days.
• Each account carries a token version counter. Incrementing it invalidates every issued session for that user at once, which is what makes an immediate revocation possible.
• Password resets use a single-use one-time code rather than a long-lived reset link.
• API keys can be bound to a single data schema, so a leaked key cannot write outside its scope.

5. The audit record

This is the control we would point a regulated customer at first.

• Every change is written to an append-only record: who did it, when, what changed, and the values before and after.
• Each entry is sealed with a keyed HMAC-SHA256 digest that covers both the entry and the digest of the entry before it, forming a chain.
• Altering or removing an entry breaks the chain from that point onward, and a single verification pass detects it and identifies exactly which entry failed.
• This is what lets you demonstrate a history is intact rather than assert it, and it is the basis of the 21 CFR Part 11 controls the product supports.
• Support access to a customer workspace is recorded in the same trail and attributed to the operator who used it.

6. Application security

• Security response headers are set on every API response.
• Cross-origin access is restricted to an explicit allow-list of exact origins. Wildcard and suffix matching are deliberately not used, because both hand credentials to a lookalike domain.
• Request payloads are size-limited, and data is validated against the schema it is being written to before it is stored.
• Dependencies are kept current, and third-party code is reviewed before it is added.

7. Data handling

• Managed database hosting with encryption at rest and automated backups.
• Access to production is limited to the people who need it to operate the service.
• The categories of provider that can access data are set out in section 7 of the Privacy Policy. The full named list, with the safeguards for each, goes to customers and prospects under a confidentiality agreement.
• The Privacy Policy covers retention, deletion and international transfers.

8. Assurance and evidence

We do not publish a control-by-control breakdown, a list of the products behind the platform, or an itemized register of what we have not built yet. A page like that is a targeting guide: it tells someone which control to test first and which system to look for a known weakness in. It is also not what an assessment actually needs.

What we do instead, for customers and for prospects under a confidentiality agreement:

• A completed security questionnaire, including standard formats such as CAIQ or SIG.
• The full named list of providers that can access data, with the transfer safeguards for each.
• A frank account of our current control gaps and the roadmap for closing them. We do not talk around them in an assessment.
• Architecture and data-flow detail proportionate to your deployment.

Ask your account contact, or write to info@sentrel.io. We answer questionnaires properly rather than deflecting them, and a customer asking about a gap is what moves it up the roadmap.

9. Reporting a vulnerability

If you believe you have found a security issue, email info@sentrel.io with enough detail to reproduce it. Please do not disclose it publicly until we have had a chance to fix it.

• We acknowledge within 3 business days.
• We will tell you our assessment and an expected timeline.
• We will credit you when the fix ships, unless you would rather we did not.
• We will not pursue legal action over good-faith research that stays within your own test data, avoids other customers' data, avoids degrading the service, and does not exfiltrate more than is needed to prove the issue.

10. If something goes wrong

We investigate, contain, and tell affected customers what happened, what data was involved and what we are doing about it. Where the law requires notification we meet its deadlines: 72 hours to the ICO or an EU supervisory authority, notification to the Data Protection Board of India under the DPDP Act, and notification to the OAIC and to affected individuals under the Australian Notifiable Data Breaches scheme where serious harm is likely. US state breach laws are handled per state.

11. Your side of it

• Use TLS for device connections in production.
• Give each person their own account. Shared logins destroy the value of the audit record.
• Scope API keys to a single schema, and rotate them when someone leaves.
• Review roles and module access when people change jobs.
• Keep your independent safety systems in place. Sentrel is a monitoring system, not a protection layer, as section 6 of the Terms explains.

12. Contact