FAQ — IoT & Fundamentum

A connectivity platform moves data — it routes messages between devices and the cloud and ensures delivery, but stays neutral about whether an action should happen. A governance platform like Fundamentum decides whether an action is allowed before it executes: it maintains device identity, enforces who can do what, controls firmware, tracks each device’s lifecycle state, and records every authorized action permanently. Connectivity asks “can this be delivered?”; governance asks “should this be permitted?”

A shared secret is one password used by a group of devices. If an attacker extracts it from a single unit, those credentials work on every device in the group — at scale, one extraction becomes a fleet-wide breach. Per-device identity gives each device a unique key, so compromising one compromises only that one, and the credential is revoked remotely in minutes. The blast radius of any breach is bounded to a single unit by design.

TLS encrypts the channel and prevents eavesdropping, but it doesn’t verify a device’s identity, enforce which commands a device may receive, or confirm the sender had permission. Complete security adds four things: per-device cryptographic identity, role-based access control enforced from the edge device through the API gateway, governed over-the-air updates with cryptographic firmware signing, and an immutable audit trail recording every authorized action permanently.

A Device Twin is a cloud-side record of what a device should look like — its desired configuration, last reported state, and any pending operations — a shadow that persists even while the device is offline. When an operator changes a setting, the change goes into the Twin; the device reads it and applies the difference when it next connects. Because desired and last-reported states are stored separately, no change is missed across connectivity gaps.

A governed over-the-air pipeline runs four stages — Prepare, Authorize, Deliver, Verify — instead of simply pushing firmware. It cryptographically signs the firmware, requires formal approval, rolls out to a small canary cohort first (typically 1–5% of the fleet), and writes a permanent record of what was delivered. Staged rollout means a bad update is caught at a small fraction of the fleet and rolled back automatically — not after it has affected every device.

With proper OTA infrastructure, the bootloader keeps the previous firmware in a protected partition. The new image is written to a separate staging partition, and the device switches only after a verified successful write. If power is lost mid-update or the new firmware fails to boot, the bootloader returns to the previous image automatically — before the device even tries to reconnect. The device boots normally and reports the failure; no technician visit is needed.

A platform should natively support MQTT/MQTTS for persistent real-time links, HTTPS for devices that communicate infrequently, and LoRaWAN for long-range low-power devices, alongside mesh networks like Wi-SUN, DigiMesh, and Wirepas. Cellular low-power connectivity is handled at the modem level and presents as standard MQTT. Industrial protocols such as Modbus, OPC-UA, BACnet, and PROFINET are bridged through an edge gateway. Most real deployments combine two or three protocols.

Three components should never be built in-house: the over-the-air update mechanism, the cryptographic identity model, and the access-control enforcement layer. Each has fleet-wide consequences if it fails and requires years of production validation to get right. Safe to customize is the application layer — dashboards, alerting rules, business logic, ERP/SCADA integrations, and device-specific data schemas. Build what differentiates your product; adopt what must be correct by design.

Relational databases struggle with IoT telemetry — they optimize transactional operations on normalized data, not analytical range queries over billions of time-ordered measurements, and degrade as data grows. Column-oriented analytical databases such as Apache Doris read only the metric being queried rather than every column of every row, completing in seconds what relational databases take minutes to do. Time-series databases excel specifically at single-metric dashboards.

Three things must be true at once: cloud-agnostic governance (identity, access control, update history, device state, and audit trail accessible independently of the platform, in portable formats); portable device identity (credentials re-provisionable over the air, designed in from the start); and offline-capable edge software so devices keep running on cached rules during an outage. Together, a platform outage becomes a service interruption rather than a fleet-wide crisis.

Prototypes succeed because small teams manually compensate for architectural gaps — hand-pushed updates, informal access, spreadsheet-tracked state. None of that scales. At production, consistent failure modes appear: shared-secret credentials, permission systems that break across teams, updates that can’t be safely automated, and observability adequate for 50 devices but meaningless at 5,000. These are architectural choices that must be resolved before the first production device ships — not bugs to fix later.

Six observable patterns: shared secrets for device authentication; manual or script-based updates with no staged rollout; permission logic embedded in application code; device state in a general-purpose database with no Device Twin; no data isolation between customers; and no offline operation mode on devices. Each is an architectural assumption that becomes exponentially more expensive to change as the fleet grows, so they are best caught before scaling.

Run the migration in parallel so devices are never offline. Deliver the new edge software through the existing update mechanism while devices keep their current connectivity; it runs in shadow mode, building state without routing production traffic. Validate registration and dual telemetry, then switch routing progressively by cohort — lowest-criticality first, verifying each before the next. Finally, revoke old credentials and update application code. Amotus has completed such migrations in weeks.

Yes, if the provisioning architecture was designed for it. While the old credentials are still valid, the platform delivers new credentials to each device as a signed update; the device installs them, verifies they work by connecting, and only then invalidates the old ones. If installation fails, the device keeps the old credentials and reports the failure. The delivery channel must use a credential that isn’t being rotated in the same operation.

Ideally before the prototype. Early decisions about authentication, firmware delivery, and permissions become technical debt that grows exponentially more expensive to change at each stage — a prototype on shared secrets refactors cheaply, but thousands of fielded devices on shared secrets cannot be fixed without physical access. The pilot stage is the last practical moment to set the architecture, before the first production device ships.

Watch for operational signals: a firmware update needing several engineers coordinating for weeks even for a few hundred devices; a support request that needs a spreadsheet check to determine what a user was authorized to do; or a customer asking for an audit log the team can’t produce without a custom query. A near-miss — targeting the wrong device group and catching it manually — is a sharper warning. When these recur, the fleet has already outgrown convention.

Fundamentum manages 850,000+ devices in production across 15+ countries, including smart-city infrastructure, energy management, and industrial IoT. When comparing vendors, ask for the current active device count (not historical) and a sector-specific reference customer — a platform with real production history has been tested under real operational conditions.

It means your telemetry, device state, and access records are stored and processed within a specific legal jurisdiction, not subject to another country’s laws. For Canadian organizations, data must not flow through US infrastructure subject to the CLOUD Act, which can compel US-headquartered companies to surrender data regardless of where servers sit. Fundamentum runs on Canadian sovereign cloud, operated by a Canadian company, with no CLOUD Act exposure and written contractual data residency.

Yes. Fundamentum can be deployed with data stored within Canadian jurisdiction, operated by Amotus — a Canadian company — with written confirmation of no foreign law-enforcement access under the U.S. CLOUD Act. For government, healthcare, and utility buyers where sovereignty is a legal procurement requirement, this is provided as a standard contractual term. It supports Québec’s Law 25 and Canada’s PIPEDA.

SOC 2 Type 2 is an independent audit confirming a vendor’s security controls operated correctly over a period of time — not just that they exist. Enterprise buyers, especially in healthcare, finance, and government, frequently require it before they will even evaluate a product. Groupe Vectanor (Amotus’s parent) is SOC 2 Type 2 audited by RCGT, and Fundamentum operates within that perimeter — so customers inherit that compliance baseline.

Ask for the full report, not a badge. Confirm a recognized auditor, that the audit period covers the last 12 months, and that the IoT platform services — not just the hosting — are in scope. Check which Trust Service Criteria are included: Security is mandatory, and Availability and Confidentiality usually matter for IoT. Fundamentum’s report is available to qualified prospects under NDA.

In an ungoverned architecture, honestly no — logs show what happened after the fact, but not that each action was evaluated against policy before executing. A governed architecture with an immutable audit trail produces a tamper-evident record per action: requesting identity, authorizing role, device lifecycle state, the allow/deny decision, timestamp, and a cryptographic hash chain. Fundamentum’s audit trail has no interface to modify or delete records, even for administrators.

Operational promises about where data lives can change without your consent. A contractual guarantee legally binds the vendor to a named jurisdiction with defined remedies. Look for five clauses: a data-location warranty, a legal-jurisdiction clause, acquisition-notification rights, data portability on exit, and a right to audit. Fundamentum provides all five as standard terms.

Most hyperscaler IoT services charge per message, connection, device, and API call. Because message volume rises as you add sensors and features, the bill compounds on two axes at once — inexpensive in a pilot, expensive in production. Fundamentum uses pricing that scales with device count, not message volume, so costs stay predictable as the product matures.

Consumption-based pricing charges for usage — messages, connections, API calls — so costs climb as your fleet and data volume grow. Linear pricing scales with device count only. For a product where telemetry naturally increases over time, linear pricing makes multi-year unit-economics projections far more credible. Fundamentum’s model is linear by design.

A firmware update is a bounded engineering cost, but a fleet-wide failure is open-ended: technicians may need to physically visit every site, plus SLA penalties, liability, and reputational damage. Industry research has documented average fleet-wide update incidents in the tens of millions of dollars. Governed updates with staged rollout and automatic rollback are designed to prevent this entire risk category.

The most commonly missed costs are legacy ERP/SCADA integration, change management and retraining, ongoing platform maintenance staff, and cloud billing as data volume grows. Building a complete multi-year financial model at the start — not phase by phase — surfaces these costs before they arrive as surprises.

Moving teams from scheduled maintenance to condition-based alerts is a months-long behavioral change across many people and sites, not a one-day training. Analyst research consistently identifies change management as a leading cause of underperformance in technically successful IoT projects. Budget it as a separate line item, not a footnote under training.

When your monthly cloud bill grows faster than your device count, and the projected cost at your three-year target fleet size exceeds the cost of adopting a platform, adoption becomes the economically stronger choice. The crossover often lands in the low tens of thousands of devices, depending on how often your devices report. A short total-cost-of-ownership assessment can pinpoint it for your fleet.

Several major cloud providers have exited IoT verticals in recent years. If your devices depend on a vendor’s proprietary identity and update services, an exit can force a lengthy, costly rebuild. A cloud-agnostic platform with portable device identity and standard protocols turns that scenario into a short migration instead of a crisis — worth weighing as a financial risk, not just a technical one. —