A monitoring gateway has to clear IT before it clears the floor. Even a plant manager fully sold on the pilot still needs someone in IT to sign off on a new device touching the machine network, and that person is going to ask a specific, fairly predictable set of questions. Knowing what they are, and what a good answer to each one actually sounds like, saves a pilot from stalling for two weeks waiting on a security review that could have happened before the kickoff call.
Does it write to the controllers
This is usually the first question, and it deserves a precise answer, not a reassuring one. A system that only reads from a PLC or CNC, connecting as a client and pulling values on a schedule, has a bounded worst case: if the connection fails, a chart shows a gap. A system that writes back, adjusting parameters, pushing programs, has become a component of the machine, with a different and larger risk profile. Ask exactly what gets written, and to what. Spall’s connection to a customer’s controllers is read-only by contract: no code path in the product writes to a PLC or CNC, ever.
Does anything connect inbound to the plant
This is the question that decides whether the gateway is a new attack surface or a one-way sensor. The right answer is that the device makes outbound-only connections: it reads machine data locally and sends it out over an encrypted channel, with nothing listening for an inbound connection from outside the plant. Spall’s edge gateway runs no remote-login service of any kind, not by default and not on request. There’s no standing tunnel and no shell to enable. If support ever needs a hands-on look, that happens in person, a visit to the on-site console or a straight device swap, never over the internet.
One thing worth stating plainly: the gateway does serve a local setup console, a page used to claim the device and configure its network at install time. It’s reachable only from the network segment the gateway sits on, not from the internet, and it can be switched off in the gateway’s own configuration once setup is done. IT should ask about this specifically, because “nothing listens on this device” is a stronger and different claim than “nothing listens except a local setup page,” and the accurate answer is the second one.
Where does the data go, and can we get it back out
IT and the floor tend to ask versions of the same question from different angles. IT wants to know the data doesn’t leak somewhere unexpected. The plant manager wants to know it isn’t locked away. Both get answered by the same fact. Data leaves through live Excel and OData feeds, direct SQL views, and a REST API, the same data a dashboard shows, queryable on the plant’s own terms and not locked inside a vendor’s interface. If a relationship ends, the plant keeps its own history instead of losing it to a vendor’s database.
Is our data separated from other customers
A shared multi-tenant system needs a clear answer to whether one customer can ever see another’s data. The right structure is isolation enforced at the API layer, every query scoped to the account it belongs to as a rule the server enforces, not a filter the client is trusted to apply correctly. A separate super-admin role for box-wide operations, kept apart from any individual customer account, is the other half of that answer: whoever can see everything should be a distinct, audited role, not an accident of how a regular account happens to be configured.
Can we require two factor authentication
This question usually comes from whoever owns the plant’s own security policy, and it has a specific, checkable answer, not a philosophy. Admin accounts should be able to enroll standard TOTP two factor authentication, with backup recovery codes, from their own account settings, and an organization should be able to turn on a tenant-wide setting that requires it for every admin account, not leave it as an individual opt-in nobody actually turns on. Ask both halves of this question, whether an individual can enable it and whether the organization can mandate it, because a vendor that only offers the first has given administrators a choice they’ll mostly decline.
How are secrets handled, and what’s in a diagnostics export
A gateway occasionally needs to hand over a diagnostics bundle for support, and IT will want to know what’s in it before that happens. Credentials and connection secrets should live somewhere access-controlled and never committed to a code repository or written to a log, with an export process that strips anything sensitive before it leaves the box, no secret value, and no field whose name looks sensitive, present in what gets sent out. Ask specifically what a diagnostics export contains and who reviews it before it’s requested. “It’s secure” is not an answer to that question.
What happens if the internet connection drops
This is less a security question and more a resilience one, but IT usually asks it in the same conversation, because it touches the same device. A gateway worth trusting keeps reading and buffering locally if the connection to the cloud goes down, and backfills once connectivity returns, so a network outage on the plant floor doesn’t erase a shift’s worth of history. Ask what happens to data captured during an outage specifically, since “it reconnects automatically” and “it reconnects and backfills everything it missed” are different claims.
What a good answer sounds like across all of it
The pattern worth noticing across every question above is the same one that shows up when evaluating any vendor claim: a specific answer beats a reassuring one. “Read-only, no code path writes to a controller” is checkable. “We take security seriously” is not. “Outbound-only, no remote-login service, here’s what the one local exception is and how to turn it off” is checkable. “It’s a secure device” is not. IT departments are trained to notice the difference. A vendor that answers in specifics instead of assurances is telling IT something true about how the product was actually built, beyond how it’s being sold.
How to report a problem
Ask, too, what happens after the sale, if someone finds a security issue later. A working answer names a real contact, a real response commitment, and a public policy page, not a vague promise to “look into it.” Spall’s own answer: email hello@spall.cc with what was found, every report acknowledged within five business days on a best-effort basis, with the machine-readable policy published at /.well-known/security.txt for anyone who wants the formal version.
Quick recap
- Confirm read-only access in writing: no code path should ever write to a customer’s PLC or CNC
- Confirm outbound-only networking: no remote-login service, no standing tunnel, and only one clearly scoped local exception
- Confirm data portability: an export, a live feed, or an API, beyond a vendor’s own dashboard
- Confirm tenant isolation is enforced at the API layer, with any super-admin access kept in a separate, audited role
- Confirm two factor authentication exists for individuals and can be mandated tenant-wide by an administrator
- Confirm what a diagnostics export contains, how secrets are handled, and what happens to data during a connectivity outage