What due diligence should we do before selecting an IoT platform vendor?
Verify five things independently: production evidence (request a reference for a deployment at your target scale, sector-identified at minimum), compliance certification (SOC 2 Type II from a named auditor, not a self-assessment), governance depth (ask specifically how RBAC is enforced at the device layer and how OTA rollback is implemented), commercial model (request a written TCO comparison at your target fleet size), and data residency (confirm in writing where your device data will reside). All five are documented for Fundamentum on amotus.com and in the Phase Zero deliverables.
What contractual guarantees should an IoT platform vendor provide on uptime and SLA?
Minimum requirements: a defined uptime SLA at the platform level (not just the MQTT broker), a documented response time commitment for severity-classified incidents, a data recovery objective for telemetry and device state, and a defined escalation path for fleet-impacting incidents. Fundamentum operates at a 99.9% uptime SLA at the platform level. SLA terms are part of the enterprise engagement agreement and are negotiated during the qualification process.
How do we evaluate an IoT vendor's security posture before giving them access to our device fleet?
Request the SOC 2 Type II report (not just the badge — the actual report from the named auditor), ask for the penetration test schedule and most recent findings summary, verify the cryptographic identity model (per-device vs. shared secrets), and confirm the RBAC model prevents cross-tenant access structurally. Fundamentum's SOC 2 Type II report from RCGT is available to qualified prospects under NDA during the evaluation process.
What does SOC 2 Type II mean in practice for an IoT platform and why does it matter?
SOC 2 Type II means that an independent auditor examined the platform's security controls and confirmed they operated correctly over the audit period — not just that the controls exist on paper. For enterprise procurement, it eliminates the need for your security team to conduct a full vendor security assessment from scratch. For regulated industries, it is frequently a procurement gate. Fundamentum's SOC 2 Type II was audited by RCGT (report dated April 15, 2026) for Groupe Vectanor. A product built on Fundamentum enters its enterprise sales cycle with this certification inherited.
How do we avoid vendor lock-in when adopting a managed IoT platform?
Fundamentum's architecture is cloud-agnostic: it deploys alongside AWS, Azure, or GCP without dependence on any hyperscaler-specific primitive. The MQTT and Kafka interfaces are standard protocols with broad ecosystem support. The Device Registry and OTA APIs are documented and versioned. Data export from the telemetry store (Apache Doris) uses standard SQL interfaces. Lock-in risk is lower with a specialized platform that uses standard protocols than with a hyperscaler-native approach that ties your architecture to proprietary services.
What happens to our device fleet if our IoT platform vendor shuts down?
This is the right question to ask. Fundamentum is operated by Amotus, a division of the Vectanor Group — a multi-division organization with 20+ years of operation and institutional continuity beyond any single product line. The platform uses standard protocols (MQTT, Kafka, REST) and open-source components, so a migration path to alternative infrastructure exists without proprietary format lock-in. The enterprise engagement agreement includes data portability provisions.
How do we negotiate data sovereignty and residency requirements with an IoT platform vendor?
Fundamentum's Canadian sovereign deployment is the default for Canadian enterprise clients — device data resides in Canadian cloud infrastructure, meeting Law 25 and PIPEDA requirements without negotiation. For specific regulatory contexts (healthcare, government, defence), data residency terms are included in the enterprise agreement and confirmed in writing before deployment. The Phase Zero Architecture Decision Record includes a data residency assessment for your regulatory context.
What should an IoT platform migration plan include to minimize operational risk?
A complete migration plan covers: current architecture assessment (what exists, what must change, what can coexist), a parallel operation period (both platforms active, no single cutover moment), a device re-provisioning strategy that does not require physical device access, a rollback trigger definition (the conditions under which the migration pauses), and a monitoring plan for the transition period. Fundamentum's Phase Zero deliverables include the Architecture Decision Record that provides the input for this plan. Amotus's engineering team supports migration execution for enterprise clients.
How do we validate that an IoT platform vendor's claimed scale is real and not marketing?
Ask for a sector-identified reference at the claimed scale, willing to confirm device count and deployment duration under NDA. Ask for the name of the auditor and the audit period for any SOC 2 certification. Ask for the infrastructure architecture that supports the claimed scale — Fundamentum's Kafka backbone, embedded MQTT broker, and Apache Doris OLAP engine are the specific components that enable 850,000+ device operation. References available by introduction during the qualification call.
What reference customers should we ask for before signing an IoT platform contract?
Request a reference in your industry vertical at comparable scale, willing to discuss architecture decisions, operational experience, and the migration or onboarding process. Fundamentum's largest production deployment — the Dimonoff smart city fleet — covers 850,000+ devices across 65 cities in 15+ countries. References are available by introduction under NDA during the enterprise qualification process. The Phase Zero engagement is itself a reference-generating experience: the deliverables demonstrate Amotus's depth before any commercial commitment is made.