What is the difference between IoT connectivity and IoT governance?
Connectivity answers: can this message be delivered? Governance answers: should this action be allowed? AWS IoT Core and Azure IoT Hub are connectivity platforms. Fundamentum is a governance control plane. It sits between your devices and your application and enforces the authority model — who can command what, what firmware can be deployed to whom, what is the device authorized to do when offline — that connectivity platforms do not provide.
What does a production-grade IoT architecture actually look like at 100,000 devices?
It has five non-negotiable layers: cryptographic device identity per device, an RBAC model enforced from edge to API without gaps, a governed OTA pipeline with staged rollout and rollback, a device twin that reconciles state across offline/online transitions, and an observability stack that provides fleet-level health visibility in real time. Fundamentum delivers all five as platform infrastructure. The Architecture White Paper documents each layer in detail.
What is a device twin and why does it matter at scale?
A device twin maintains two states simultaneously: what the device reports (current reality) and what the platform desires (target configuration). When a device reconnects after being offline, the twin reconciles the gap automatically — pushing missed configuration changes, flagging state drift, and ensuring the device reaches its desired state without manual intervention. At 100,000 devices, this reconciliation happens continuously and automatically across the entire fleet.
What causes firmware updates to brick devices in production?
Three causes dominate: no atomicity guarantee (a power loss mid-flash leaves the device in an unrecoverable state), no staged rollout (a bad update reaches the entire fleet simultaneously), and no authorization gate (any actor with API access can trigger an update to any device). Fundamentum's governed OTA pipeline is atomic by design, staged by default, and requires explicit authorization before any update reaches any device.
How do you manage device identity and authentication across a large IoT fleet?
Fundamentum assigns each device a unique cryptographic identity — an RSA key pair — at provisioning. Every connection is authenticated against that identity. No shared secrets. No API-key-per-device models that become a single point of compromise at scale. A decommissioned device cannot reconnect: its identity is revoked at the provisioning layer, not the application layer.
What is RBAC in IoT and why does our current permission model not scale?
Role-Based Access Control in IoT means that every action — device command, firmware update, telemetry read, API call — is evaluated against a consistent authority hierarchy before it executes. Most teams assemble RBAC from fragments (IAM + API Gateway + application code) that develop gaps under load. Fundamentum's RBAC is a single model: Organization → Project → Resource. One rule set, enforced at every surface, with no gaps between layers.
How do you handle IoT devices that go offline and reconnect with stale data?
Fundamentum's Rust edge daemon buffers telemetry locally during disconnection and transmits it in order on reconnect. The Device Twin's desired-vs-reported reconciliation closes any state drift that accumulated while the device was dark. The device does not make new decisions it was not authorized to make before the connection dropped. Offline behavior is bounded and deterministic by platform design, not by per-device firmware implementation.
What is the difference between IoT device management and IoT fleet governance?
Device management is operational: reboot this device, update that firmware, read this telemetry. Fleet governance is architectural: define who is allowed to reboot any device, authorize which firmware versions can reach which device groups, ensure every action has an immutable audit record. Fundamentum provides both — the action dispatcher handles device management operations, and the governance control plane ensures every operation is authorized, logged, and attributable.
Why is multi-tenant IoT so hard to get right on AWS or Azure?
Because hyperscaler IoT services are not designed with multi-tenancy as a first-class architectural primitive. Tenant isolation is assembled from IAM policies, VPC configurations, and application-layer checks — all of which can develop gaps. Fundamentum's Organization → Project → Resource hierarchy is multi-tenant by design. Tenant A cannot reach Tenant B's devices structurally, not by policy convention.
What does end-to-end IoT security actually require beyond TLS?
TLS encrypts the transport. It does not authenticate the device's identity, enforce what commands the device is authorized to receive, or guarantee that a firmware update was explicitly approved before delivery. End-to-end security requires: per-device cryptographic identity, RBAC enforced from edge to API, governed OTA with authorization gates, and an immutable audit trail of every action. Fundamentum provides all four. The platform is SOC 2 Type II audited, confirming that these controls operated correctly over the audit period.
How do you enforce permission policies from the edge device to the cloud API consistently?
Fundamentum's RBAC model is enforced at every layer by the same authority hierarchy. The edge daemon executes only within the authority boundary set by the cloud. The API gateway validates every call against the same RBAC model. There is no separate permission system at the edge and another at the API. One model, one enforcement point, consistent results across all surfaces.
What is the total cost of ownership of a self-built IoT platform versus a managed one?
The Architecture White Paper documents the DIY build cost at $1.5M–$2.8M over 18–30 months for a production-grade governance stack — before SOC 2 compliance, which adds $180K–$350K and 12–18 months. Fundamentum's TCO model, delivered as part of Phase Zero, produces a three-scenario financial comparison calibrated to your team's size and timeline. Most teams find the crossover point — where Fundamentum costs less than the ongoing cost of maintaining their self-built stack — within 18 months.
What are the operational risks of running IoT OTA updates without a governed rollback mechanism?
A firmware update without governed rollback is a single point of catastrophic failure for your entire fleet. The $37.5M automotive OTA incident — a publicly documented fleet-wide failure — is the reference case. Fundamentum's OTA pipeline is atomic: a device that loses power mid-update rolls back to its previous firmware automatically. A cohort that fails health verification stops the rollout before it reaches the next cohort. These are structural guarantees, not operational procedures.
How do you calculate the real engineering cost of building IoT infrastructure in-house?
Count the capabilities, not the lines of code: cryptographic provisioning, MQTT broker with session persistence, Kafka event backbone, multi-tenant RBAC, governed OTA, Device Twin, observability stack, SOC 2 program. The Architecture White Paper provides component-by-component estimates with timeline and risk. The total is consistently $1.5M–$2.8M before the SOC 2 audit period. Most teams that do this calculation accurately choose a different path.
What are the most expensive mistakes companies make when building their own IoT platform?
Three dominate: starting with shared secrets instead of per-device cryptographic identity (forcing a fleet-wide re-provisioning project later), building RBAC at the application layer instead of the infrastructure layer (creating gaps that become security incidents), and deploying OTA without a staged rollout and rollback mechanism (creating the conditions for a catastrophic fleet-wide update failure). Fundamentum's architecture eliminates all three by design.
What is the cost of a failed OTA firmware update across a fleet of 50,000 devices?
At $37.5M for a documented automotive case, the per-device cost of recovery is well-established. Recovery requires field engineering visits, replacement hardware for unrecoverable devices, customer compensation, and the engineering time to diagnose and rebuild the update pipeline correctly. Fundamentum's governed OTA pipeline — authorization gate, staged rollout, atomic execution, automatic rollback — is the architecture that prevents this scenario structurally.
How do you know when your IoT architecture needs to be rebuilt versus patched?
If your permission model is assembled from fragments across multiple systems, if your OTA process has no staged rollout or rollback, if your device identity uses shared secrets, or if your observability cannot answer "what is the state of my fleet right now" — you need a rebuild, not a patch. Phase Zero produces an Architecture Decision Record that makes this assessment objectively, with a Risk Map that quantifies which failure modes your current architecture is exposed to.
What is IoT technical debt and how do we measure ours?
IoT technical debt is the accumulated cost of architectural shortcuts that must eventually be corrected in production. Measure it by listing the components that would need to be rebuilt to meet production-scale governance requirements: per-device identity, consistent RBAC, governed OTA, offline state management, observability. Phase Zero's Governance Readiness Assessment produces exactly this inventory, scored against the requirements of your target markets.
Why does our IoT platform not meet enterprise security procurement requirements?
Enterprise procurement typically requires SOC 2 Type II certification, per-device authentication (not shared secrets), documented access control with audit trails, and data residency options. Building a SOC 2 program from scratch takes 12–18 months and $180K–$350K. Fundamentum is SOC 2 Type II audited by RCGT. A product built on Fundamentum operates within that audited environment from day one.
What compliance certifications does an IoT platform need to sell into regulated industries?
Healthcare requires HIPAA-compatible data handling and audit trails. Energy requires NERC CIP-aligned access control. Government and defence require sovereign data residency and, in Canada, CCCS-aligned security controls. Fundamentum provides SOC 2 Type II as the baseline, Canadian sovereign cloud deployment for Law 25 and government requirements, and the audit trail infrastructure that regulated markets require for every device action.