MQTT in GxP and GMP-regulated environments

TrailMQ is a technical control, not a compliance outcome. This page states its boundaries and points to the guides that cover the rest.

Last updated: September 2026

No product is GxP compliant by itself. Compliance is a property of a validated system operated under a quality system, not of a component you install. What a broker can do is contribute technical controls that a validation strategy then assesses.

The context TrailMQ is designed to be assessed in: GMP (manufacturing quality), GAMP 5 (risk-based validation), 21 CFR Part 11 (electronic records) and ALCOA+ data-integrity principles. Naming them describes the context, not conformity.

What TrailMQ contributes

Two independent authorization gates, with unconfigured namespaces closed until a rule opens them. Attributable allow and deny records carrying actor, role, client id, action, topic, time, outcome and reason. Sign-ins, administrative changes and policy or topic-rule changes recorded as system and action entries. And a hash-linked integrity chain over those entries that reports its own scope, including what it excludes.

See a decision · what a decision record contains

Where it stops

TrailMQ is not a compliance certification or conformity assessment, a GMP/GxP validation package, an Annex 11 package, a 21 CFR Part 11 package, a CE declaration, WORM storage, a notarization service, or a guarantee of message delivery.

On integrity specifically, because this is the claim most often overstated in this market: the hash-linked chain walks the system and action store — sign-ins, administrative changes, identity and role changes, policy and topic-rule changes. It does not walk MQTT message evidence, including publish and subscribe refusals, which live in their own store. The product labels those records Outside validated scope and repeats the limit beside the verdict. The chain is also not externally anchored and not digitally signed, so it demonstrates internal consistency rather than third-party custody.

If your requirement is a tamper-checked record of every individual MQTT decision, TrailMQ 3.1.0 does not provide that today. Extending integrity coverage over MQTT decision records is planned for 3.2 and is not available now.

Two further boundaries worth knowing during evaluation. The public package is for local, non-production evaluation; demo certificates and generated users are not deployment-ready. And configuration sync uses merge semantics, so removing a user from config.yaml does not revoke a user already persisted in the runtime database — follow the documented offboarding path.

Validation, risk assessment, supplier assessment and procedural controls remain the responsibility of the regulated organisation.

The underlying questions, in depth

Evaluate the technical controls directly

Trigger a denial yourself and read the record it produces, including the integrity verdict's stated exclusions.