Security

What ShiftRounds holds

For each plant, ShiftRounds holds its name and time zone, its checkpoints and the equipment at each, the limits each reading is judged against, and every round: readings, status, leaks, faults, notes and photos of plant areas. It also holds when rounds are due, whether they were walked, and who walked them.

Together, that shows the condition of a named plant and when people are on its floor. Review it as operational security information, not ordinary business data, and apply your own classification and records rules to it. ShiftRounds doesn’t ask for a plant’s street address.

Keeping utilities apart

The database decides. Row-level security is on for every table. Each record carries its utility, set by the database from its plant or round, never taken from the app. A request that isn’t entitled to a record doesn’t get it, so a mistake in the app or the console can’t show one utility’s records to another.

The app and console hold no master key. They use the public key and the signed-in person’s own session for every read and write, so row-level security applies to the console’s server too. Only our server functions hold keys that bypass it.

Phones don’t write rounds directly. A phone sends what it recorded to a server function. The function checks every item before it stores any, and works out each finding itself, with the same rules the phone uses. A phone can’t mark its own reading as fine.

Sensitive changes go through checks. Signed-in people may update only the columns the app needs, one by one. Changing a role, removing a person, setting a PIN, and assigning or closing an issue each go through a database function that checks who’s asking.

Report links need a sign-in. A round report’s link opens only for someone signed in who may read that round.

Roles and plants

Each person has one role: owner, chief operator, supervisor, buyer, operator or user. Owners, chief operators and buyers see every plant in their utility, and so does a supervisor given full access. Everyone else sees only the plants they’re given, and someone limited to one plant doesn’t see the others at all. A user sees only the rounds they walked.

• Owners and chief operators change roles, never their own. Only an owner makes someone an owner.
• Supervisors set up routes and checkpoints, and look after operators and users at their plants.
• An owner or chief operator can give a supervisor full access: every plant, and the people as a chief operator looks after them. Even then, that supervisor can never change, remove or set the PIN of an owner, a chief operator or another supervisor with full access, or make anyone a chief operator or owner.
• Nobody can remove themselves, so a utility can’t lock itself out that way.

When someone is removed, their access ends at once. Anything their phone hadn’t sent is refused from then on. Their name stays on the records they made.

Records that can’t be rewritten

Readings, tag taps, published route versions, issue history and the change log are append-only. A database trigger refuses any change to them from the app, the console or our server functions’ ordinary work. A corrected reading is a new entry: the earlier one stays, and the latest one taken stands. The one exception is deleting an account: it takes the person’s email address out of the change log, and when a utility goes with its last member, its records go with it.

Every reading names the person who took it, and the shared device when it came from one. It carries the time on the phone’s clock when it was taken, the time the server received it, and how far the phone’s clock was from the server’s.

The change log. Changes to plants, areas, people, roles, devices, checkpoints, tags, routes and alert settings are logged with who made them, when, and the values before and after. PIN hashes never enter the log. Owners, chief operators and supervisors given full access can read their own utility’s log.

Sign-in

• Passwords are at least 12 characters. Our sign-in provider stores them as salted hashes, and nobody here can read them.
• A new account must confirm its email address before it can set up a utility, so an address nobody controls can’t become a utility.
• A password reset link works once, for a limited time.
• Anyone can turn on two-step sign-in, with a code from an authenticator app. Once it’s on, the database refuses that person’s requests until the code is entered, not just the sign-in screen.
• Turning it on also gives ten one-time recovery codes, shown once, for a lost authenticator app. The database keeps only a hash of each. With the password, one turns two-step sign-in off so it can be set up again, and the account’s email is told. Wrong codes are counted: ten in an hour, and the next try waits.
• An invitation link carries a random code, works once, and runs out after seven days. The database keeps only a hash of the code. Sending an invitation again makes a new code, and the old link stops working.
• Sign-up is open only to utilities in the United States.

Phones and shared devices

Offline by design. Rounds are saved on the phone first and sent when there’s signal. Each item is sent with an id made on the phone, so sending it twice stores it once.

The stored sign-in. The app keeps its sign-in encrypted on the phone, with the key in the phone’s keychain.

Face ID lock. A personal phone can lock ShiftRounds with Face ID, Touch ID or a fingerprint. It asks when the app opens and after 10 minutes in the background. The phone’s passcode stands behind it, for an operator in a respirator or wet gloves. It’s optional, and the match happens on the phone.

Shared devices. A supervisor enrolls a shared device, such as a control-room iPad, with a one-time code that works for 30 minutes and is stored only as a hash. The device signs in as itself, limited to its plants. Each person unlocks it with a four-digit PIN, stored only as a salted SHA-256 hash and checked on the device so it works with no signal. Wrong PINs bring a wait, and five lock that person on that device until a supervisor sets a new PIN. A PIN is a convenience lock on a device that already holds a session, not an account password.

Removing a device. A device removed in the console loses its access on the server at once. The next time it reaches the server, it forgets its roster. Anything it hadn’t sent stays on it, unsent. A device that never reconnects keeps working offline with what it has, so take it back physically as well.

Photos and tags

Photos come only from the app’s camera, never the photo library. Each is saved again before it leaves the phone, which removes the camera’s details from the file, location included. Photos sit in a private storage bucket. A device may upload only to the place set for a photo the server already knows about. Pages show photos through signed links that last an hour.

NFC tags carry only a ShiftRounds link with a short code, and a line that tells an Android phone to open the app. The page the link opens says nothing about the plant or the checkpoint. A tap counts when the app reads the tag’s factory serial number, and the server matches it to the area or checkpoint the tag is on. “Tapped” means the phone touched the tag of the checkpoint’s area within the hour before the checkpoint was finished, or, for a checkpoint with a tag of its own, that tag within 15 minutes. A determined person can copy a tag’s serial number onto another chip.

Email

ShiftRounds sends email from send.shiftrounds.com, through Resend. The messages are signed, and shiftrounds.com publishes a DMARC policy that tells receiving servers to reject mail that fails the check. Our emails don’t track opens or clicks. Replies to a report go to the utility’s chief operator, not to us.

A report email carries the round’s findings, with their readings, and up to eight photos. Once it’s in someone’s inbox, it’s outside ShiftRounds’ control and can be forwarded. Choose report recipients with that in mind.

Access from outside the US

The website and the console refuse requests from outside the United States. That stops a share of opportunistic scanning before it reaches a sign-in form. It’s one layer, not a boundary: anyone determined can route through a US address.

The block covers this page too. A reviewer outside the US can’t reach it, and should ask us for it at info@shiftrounds.com. The app talks to our database and sign-in service directly, and that service isn’t blocked by country. Sign-in and row-level security protect it.

What it doesn’t do yet

These are the gaps a reviewer would find.

• No independent audit. There’s no SOC 2 report. The practices here are our own, and no auditor has checked them. If your purchasing rules require an attestation, ShiftRounds doesn’t meet them yet.
• No single sign-on, and two-step sign-in isn’t required. Each person signs in with an email address and a password, and chooses whether to add a code. A utility can’t require it yet.
• Rounds on a phone aren’t encrypted by ShiftRounds. They rely on the phone’s own protection, so keep a passcode on every phone and tablet that walks rounds. Photos stay on the phone after they’re sent.
• The Face ID lock covers the screen, not the stored sign-in. That’s on purpose, so readings keep sending while the phone is locked and an operator with no signal can always get in.
• Export covers readings. Export in the console downloads a plant’s readings, and its meters’ daily flow, as a spreadsheet; the app emails the same file to the person who asks. Photos, issues and the change log aren’t in it yet. Ask us for a copy of those.
• Tags can be copied. Tags that can’t be (signed NTAG 424 DNA tags) aren’t supported yet.
• It’s a record, not a control system. ShiftRounds doesn’t connect to SCADA or any plant equipment, and it doesn’t actuate anything.

Where it runs

• The database, sign-in, photo storage and server functions run on Supabase, in Amazon Web Services’ US East region (us-east-1, Northern Virginia).
• The website and console are served by Vercel.
• Every connection to ShiftRounds uses HTTPS.
• Database changes reach production only by hand, after a dry run lists exactly what will change. Nothing deploys to the database automatically from a code change.
• Our own access. Row-level security keeps utilities apart. It doesn’t keep out the people who run ShiftRounds, who can reach the production database to operate and support it, and use it only for that.

Services we rely on

• Supabase: database, sign-in, photo storage and server functions. Holds the records described above.
• Vercel: serves the website and the console.
• Resend: sends sign-up, password, invitation, report, alert and billing emails, and messages from the contact form on this website.
• Stripe: takes payments and sends invoices and receipts. Card details go to Stripe and never reach our servers.
• Expo: delivers app updates and push alerts. Push alerts go by way of Apple’s push notification service on iPhone and iPad, and Google’s Firebase Cloud Messaging on Android, and an alert’s title and short text pass through both.
• Sentry: receives error reports from the app, the console and our servers, and timings from a sample of the app’s screens. They say what broke or what was slow, and where in our code. Those from the app and the console carry no readings, notes, photos, names, email addresses or IP addresses; those from our servers carry the error’s own words, with any email address and any link’s query taken out.
• Apple: distributes the app on the App Store, and through TestFlight to people testing new versions.
• Google Play: distributes the Android app, and new versions to people testing them.
• Google Workspace: hosts our support mailbox.
• Cloudflare: hosts the DNS for shiftrounds.com. Holds no account or plant data.

Our Privacy Policy says what each one receives.

Reporting a problem

Send security questions, suspected weaknesses and reports of misuse to info@shiftrounds.com with “Security” in the subject. Say what you found, where, and how to see it again. Please don’t read another utility’s records, change anything, or slow the service down while you look.

Utilities reviewing ShiftRounds can send their security questionnaire to the same address.