Security from device to cloud.
A connected fleet is only as trustworthy as its weakest link, and that link is usually the one nobody assigned an owner. SPIDEX treats identity, transport, access and audit as platform services rather than per-product work.
Every hop is accounted for.
Device
Distinct identity, protected credentials, verified firmware.
Link
Authenticated, encrypted transport between device and platform.
Broker
Remote sessions brokered and authorised rather than exposed as open ports.
Platform
Tenant separation, role-based access, recorded configuration changes.
Operator
Named accounts, scoped permissions, session logging.
What the platform provides.
Device identity
Every device carries a distinct identity used for authentication and audit.
Secure provisioning
Credentials and configuration are applied during a controlled onboarding step.
Authentication
Devices, users and services authenticate before any command or data path opens.
Encrypted transport
Device-to-platform communication is encrypted in transit.
Certificate handling
Certificate-based trust, with support for customer-operated PKI.
Access control
Role-based permissions govern who can view, command or update which devices.
Auditability
Configuration changes, commands and access sessions are recorded.
Secure OTA
Firmware images are verified before they are accepted by a device.
Remote access control
Terminal sessions are brokered, authorised, time-bound and logged.
Fleet security posture
Firmware versions and device state are visible across the fleet.
SPIDEX describes these as engineering capabilities of the platform. No compliance certification or formal security standard is claimed here — certification status is confirmed in writing during evaluation.
Run the security review before the pilot, not after it.
Send the questionnaire. We answer platform capabilities directly and flag anything hardware-dependent for verification rather than guessing.