Encryption, keys, and data residency for industrial SaaS

Security reviewers ask three questions about any SaaS platform: is the data encrypted, who holds the keys, and where does the data live. For an industrial inspection platform the answers are more involved than for a CRM, because the data is spread across a database, an object store full of photos and drawings, backups, and a fleet of field tablets that spend days out of coverage. This paper lays out what each answer should contain, what a vendor's wording usually hides, and how to phrase the residency question so that the answer is contractual rather than descriptive.

What does encryption at rest actually cover in industrial SaaS?

"Encrypted at rest" is a claim about specific stores, and industrial SaaS has more of them than most.

• The primary database. Asset hierarchy, CMLs, readings, findings, users, roles, audit events. Almost every vendor encrypts this, usually with AES-256 through the cloud provider's storage encryption.
• Object storage. Photos, videos, PDFs, annotated drawings, workbook imports, generated reports and converted 3D models. This is where the volume is, and it is the store most often left out of the sentence.
• Backups and snapshots. Encrypted database volumes do not automatically mean encrypted backups. Ask.
• Logs and the audit trail. Audit events carry IP addresses, user agents and actor identities. They are personal data and security data at once.
• Field devices. Offline data waiting to sync. Covered separately below because it is the store the vendor does not operate.

The right question is not "is the data encrypted at rest" but "name each store that holds tenant data and state how it is encrypted." The expected answer for the cloud stores is AES-256. The expected answer for how the keys are handled is the subject of a later section.

One more distinction: encrypting the disk is not the same as encrypting a field. Storage-level encryption protects against a stolen volume or a decommissioned drive. It does nothing against a query run by someone with database access. That is why some data needs application-layer encryption on top.

Which TLS posture should you require in transit?

Data in transit is the easier half, provided the requirement is applied everywhere.

• Minimum TLS 1.2, TLS 1.3 preferred, with SSL 3, TLS 1.0 and TLS 1.1 disabled at the load balancer.
• Applies to every client: the browser, the mobile field app during sync, API calls from integrations, and webhooks or scheduled exports the platform sends outward.
• Applies inside the vendor too: connections from the application tier to the database and object storage should be encrypted, not just the public edge.

Ask how the mobile app validates the server certificate and whether it will connect over a downgraded protocol if a corporate proxy interferes. Ask whether the API rejects plain HTTP outright or redirects it. A redirect means the first request, with any credential it carried, went in the clear.

Where do the secrets live: MFA seeds, API keys and application-layer encryption?

A handful of values in an inspection platform are more sensitive than the inspection data itself because they grant access to it.

MFA seeds. A time-based one-time password seed is a shared secret. Anyone who reads it can generate valid codes indefinitely. Because database encryption at rest does not protect against a query, the seeds should be encrypted at the application layer, for example with AES-256-GCM under a key the database tier does not hold. Then a database dump yields ciphertext, not second factors.

API keys. Keys should be signed tokens bound to a tenant and a role, never stored as reusable plaintext credentials. Verification should not require a table of live keys that can be read.

Session tokens. Short-lived, signed, and invalidated when the underlying permissions change.

The general principle: encryption at rest is a property of storage; protection of secrets is a property of the application. Ask for both, and ask which values get the second treatment. Be wary of the phrase "field-level encryption of all personal data." It is rarely true, it would make the data unsearchable, and a vendor who claims it usually means storage encryption. A precise answer ("MFA secrets and these specific values are encrypted at the application layer; the rest relies on AES-256 at rest") is more trustworthy than a sweeping one.

What about data on the field device?

The field tablet is the store the vendor does not run, and it is the one most likely to be left in a truck.

An inspection app that works offline holds, at any given moment, the work packs for the unit, prior readings and drawings for reference, and the readings, photos, videos and signatures captured since the last sync. On a long outage that may be a week of a crew's work. If the local store is plain, a lost tablet is an unlogged export of everything on it.

Requirements:

• Offline data encrypted at rest on the device, independent of whatever disk encryption the operating system applies, and covering attachments as well as form fields.
• Credentials cached for offline identity checks are protected the same way.
• No expiry that destroys data. A local store that deletes itself after a fixed number of days to "limit exposure" also deletes the readings a crew has not been able to sync. Encryption is the exposure control; deletion is data loss.
• Sync over TLS, with the same certificate validation as the web client.

Ask the vendor to show you a device in airplane mode with a day of captures on it, then explain what an attacker with the device and no credentials could read.

What is data residency, and what should you ask a vendor?

Data residency is where your data is physically stored and processed. For operators with national data rules, export-controlled facilities or contractual constraints from an asset owner, the answer has to be specific and it has to be written down.

The question splits into parts that often have different answers:

1. Primary database region.
2. Backup and replica regions. Cross-region replication for resilience is common and can move data out of the country without anyone deciding to.
3. Object storage region, for photos, drawings and models.
4. Log and audit storage, which often flows to a central observability platform in a different region.
5. Where operations and support staff access data from, and under what access control and logging.
6. Sub-processors, meaning any third party that processes tenant data on the vendor's behalf, and where they are.

For each part, ask whether the answer is contractual or descriptive. "We currently host in region X" is a fact about today. "Tenant data will remain in region X, including backups, and any change requires your written consent" is a commitment. Get the second.

Who holds the keys, and how are they rotated?

Key management is the part of the encryption conversation that decides who can actually read the data.

• Provider-managed keys. The cloud provider generates and holds the keys; the vendor's application uses them through the provider's key service. Simplest and most common. Your data is protected against the disk being stolen and against the provider's other customers, and it depends on the vendor's own access controls for everything else.
• Vendor-managed keys in a key service. The vendor controls key policy and rotation but the material stays in a hardware-backed service. Ask about rotation schedule and about who in the vendor can change key policy.
• Customer-managed keys. You supply or control the key, and can revoke it. Powerful, operationally heavier, and not universally offered. If you need it, ask early; it changes the architecture.

Whatever the model, ask three things: how often keys rotate, how key access is logged, and what happens to backups encrypted under a key that has been rotated or revoked. Then ask the same about the application-layer keys protecting secrets, which are often managed separately from storage keys.

Encryption tells you the data is unreadable without the key. Key management tells you who has the key.

How intelliSPEC handles it

intelliSPEC encrypts tenant data with AES-256 at rest on both the database and the object storage, and requires TLS 1.2 or later in transit for the web app, the mobile field app and the API. MFA secrets are protected with application-layer AES-256-GCM, separately from storage encryption, so a database read does not yield working second factors. API keys are tenant-bound signed tokens tied to a role. intelliSPEC does not claim field-level encryption of all personal data; the protected values are the specific secrets named here.

The offline field app encrypts offline data at rest on the device. The local store has no time limit, so a crew's captures are never deleted for want of a sync, and sync runs over TLS.

Tenant isolation is enforced at the repository chokepoint: a write with a mismatched tenant is rejected and logged, requests are tenant-scoped, and each tenant carries its own hash-chained audit trail. Data export and import are audit events with actor, tenant, request id, IP and user agent.

Region, backup and sub-processor specifics are questions to put to the security review; the Trust Center, where controls are mapped to the SOC 2 Trust Services Criteria, is the starting point. For the wider checklist a reviewer should bring to an asset-integrity vendor, see the security review checklist for asset integrity software. Field-side encryption and offline behavior are described on the intelliINSPECT page, and pricing tiers are on the pricing page.