Security and governance

Encryption and network posture

Data is encrypted in transit and at rest.

• Key management runs on AWS KMS. Tenant-specific keys are available as an option.
• All communication runs on TLS 1.2 or higher. The browser session runs over HTTPS, and the MQTT link from site runs over TLS.
• Databases sit in private VPCs. They are not exposed to the internet, and they are reachable only by the platform backend, which authenticates with a JWT.
• The site connection is outbound from the customer network, so no inbound hole in your firewall is required.

Data residency is set per customer at onboarding: AWS Canada Central in Montreal for Canadian data, US-East or US-West for US data, with no cross-border movement unless it is explicitly configured. Architecture and deployment has the full deployment picture and the site data path.

Identity and access

Identity runs on OAuth 2.0 with AWS Cognito as the identity provider. Cognito issues JWTs for the session, and it supports multi-factor authentication and password policies.

Tenant isolation is enforced by tenant ID together with IAM policy. One customer’s data is not reachable from another customer’s session.

Inside a tenant, access is granted by module, action, role, and site. Every one of them is enforced.

Module

Each functional area of the platform is enabled per company, so a company reaches only what it has licensed and turned on.

Action

Named permissions gate individual operations, not just whole screens. Releasing a quality hold and viewing a process record are separate grants.

Role

Roles are composed from those named permissions. A standard set ships and can be copied and adjusted rather than built from nothing.

Site

A user reaches the sites they have been granted. Multi-site access is explicit, including an all-sites grant where that is what the job needs.

Agent actions are governed separately, by the Authority Matrix. Every agent carries an authority level per action type: observe, inform, suggest, act with approval, or act autonomously. Authority is checked before an agent acts, and a level that is not set defaults to suggest, so the fail-safe is the restrictive one. Authority can be conditioned, for example capped at a maximum value or scoped to named sites, and anything short of autonomous routes to a person through an approval workflow.

Where identity stops today

No federation

There is no SAML, no Entra ID, and no Okta federation today. Cognito is mode40’s own identity provider, so users sign in there rather than through your directory.

No admin console

There is no self-service administration screen. User and integration credentials are issued during onboarding, which means mode40 provisions them by hand and changes go through mode40.

No row, column, or field-level security

Access is decided at the module, action, role, and site levels described above. There is no per-record access list, no column-level restriction, and no data classification field on a record. If your requirement is that two people with the same role must see different rows of the same table, the platform does not do that today.

No export-control enforcement

The platform does not classify records for export control and does not restrict access by nationality. Regimes such as ITAR and CMMC turn on exactly those two things, so meeting them stays a matter of your own process and the scope of what you connect. What the platform contributes is role-based access, site scoping, and a complete access record.

Audit and logging

Audit logging is real, and it sits at the infrastructure level. AWS CloudTrail records activity across the account. AWS GuardDuty monitors continuously for unauthorized access. Both are operated by mode40.

Inside the platform, the Historian is a shipped module holding timestamped operational history, so the record of what happened on the floor is captured as it happens.

There is no customer-facing screen documented today that traces a given number back through its sources, so treat provenance questions as an implementation topic. The Trust Registry, which holds a verification record, is on the roadmap and is not available.

Your data

These are contract terms from the licensing agreement. The signed agreement governs.

• On termination, mode40 returns all customer data in a mutually agreed format, or deletes it, on written request.
• Backup and archival copies are securely deleted within 90 days.
• Termination for convenience takes 90 days’ notice. Termination for cause takes 30 days, with a cure period.
• Liability is capped at 12 months of fees.
• The service is provided on an AS IS basis, with other warranties disclaimed.

Your data has the exit terms in full, the notice periods, and what the agreement leaves undefined.

Availability and support

The contractual availability term is 99.5%, measured monthly, excluding scheduled downtime and force majeure. That is the only availability number that exists, and it is the one to hold mode40 to.

Support hours, channels, severity levels, and response targets are set per engagement. No standard tiers are defined, so a customer who needs specific response times should get them written into the agreement rather than assume a published tier applies.

Also undefined today:

• No public status page.
• No published release cadence. Release notes are posted on the changelog, and the agreement commits to standard software updates without attaching a cadence.
• No documented disaster-recovery plan, and no published recovery point or recovery time target.
• No separate sandbox environment.
• Data retention and purge policy is defined by the customer during implementation.

Certifications: where mode40 stands

What is in place today:

• Encryption in transit and at rest, with AWS KMS key management and optional tenant-specific keys.
• TLS 1.2 or higher on all communication.
• Databases in private VPCs, reachable only by the platform backend under JWT auth.
• Tenant isolation enforced by tenant ID plus IAM policy.
• MFA and password policies through Cognito.
• CloudTrail activity recording and GuardDuty monitoring.
• Per-customer data residency, with no cross-border movement unless configured.
• Return or deletion of customer data on termination, and backup deletion within 90 days.
• A 99.5% monthly availability term in the agreement.

What is not in place: mode40 holds no third-party security certifications. mode40 does not hold SOC 2 Type II. mode40 does not hold ISO/IEC 27001:2022. Neither audit is underway. Both are on the roadmap without a committed date, and the current status and plan are available on request.

PIPEDA sits in a different category. The licensing agreement commits mode40 to PIPEDA in its breach-notification clause. That is a stated compliance commitment, not a third-party attestation, and no certificate exists for it.