{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/", "item": { "id": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/", "slug": "keep-axis-mqtt-event-publication-filters-at-the-topic-layer", "url": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer.md", "json": "https://update.dsesecurity.com/api/v1/posts/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/" }, "title": "Keep Axis MQTT event publication filters at the topic layer", "summary": "Axis MQTT Event Bridge publication filters apply to event topics, not payload content. Design event selection at that documented boundary before connecting downstream automation.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T00:10:28+00:00", "modified_at": "2026-10-29T00:10:34+00:00", "reviewed_on": "2026-10-28", "reading_minutes": 3, "word_count": 518, "potentially_affected": "Axis devices exposing the documented MQTT Event Bridge interface; confirm support and the installed API/software scope before applying the proposed checks.", "dse_recommendation": "DSE recommends writing a two-column contract for publication selection and downstream interpretation before enabling automation.", "primary_source": { "name": "Axis Communications — MQTT Event Bridge", "url": "https://developer.axis.com/vapix/network-video/mqtt-event-bridge/", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: Choose the event topics at the Axis bridge, then place any required payload decision in a separately designed consumer.

\n

Source fact: documented behavior

\n

The MQTT Event Bridge documentation says event publications are enabled only after filters have been set.

\n

Those publication filters apply only to topics; payload filtering is not possible through that filter configuration.

\n

The documented configuration-read operation returns the current event publication configuration.

\n

What the source does not establish

\n

Do not assume that a topic filter expresses a condition on a field inside an event payload. Keep bridge selection separate from the broker connection checks and application rules. Require the actual event-topic contract for the device and integration before approving a topic pattern. Do not present the proposed consumer design as a feature supplied by this API.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

The following steps are DSE recommendations based on the cited source.

\n

DSE recommends writing a two-column contract for publication selection and downstream interpretation before enabling automation.

\n
    \n
  1. Describe the desired input without starting from a wildcard. For a proposed pilot, select one required event topic and one nearby topic that should remain excluded. Write the operational reason for each selection. If the requirement refers to a payload value, put that condition in the consumer column and assign an owner to design it. Do not relabel the payload requirement as a bridge filter.
    2. \n
  2. Apply the supported topic selection on a test device, then read the current publication configuration back. Compare that returned configuration with the intended topic list. Keep this evidence separate from proof that the MQTT client connects to its broker. An integration worksheet should give each of those checks its own result and owner.
    3. \n
  3. Exercise representative included and excluded events through an authorized test arrangement. At the consumer, compare the received event topic and payload with the written contract before allowing a consequential action. Use a logging-only destination first where practical. Review unexpected traffic as a selection or interpretation problem, rather than widening filters until an application appears to work.
    4. \n
\n

Verification and evidence

\n

Preserve the intended topic list, returned bridge configuration, sanitized broker observations and consumer decision record. Use stable test labels so a reviewer can tell the deliberately excluded event from a missing required event. Record any payload logic as separately maintained application behavior.

\n

Repeat the proposed cases after changing topic filters, device software or the consumer’s event mapping. Include a requirement that cannot be expressed by topic selection alone and confirm that the design review routes it to the appropriate consumer work. These are proposed DSE verification steps, not a claim that any MQTT deployment or automation was tested.

\n

Official references

\n\n

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.

\n", "content_text": "Bottom line: Choose the event topics at the Axis bridge, then place any required payload decision in a separately designed consumer.\nSource fact: documented behavior\nThe MQTT Event Bridge documentation says event publications are enabled only after filters have been set.\nThose publication filters apply only to topics; payload filtering is not possible through that filter configuration.\nThe documented configuration-read operation returns the current event publication configuration.\nWhat the source does not establish\nDo not assume that a topic filter expresses a condition on a field inside an event payload. Keep bridge selection separate from the broker connection checks and application rules. Require the actual event-topic contract for the device and integration before approving a topic pattern. Do not present the proposed consumer design as a feature supplied by this API.\nApplicability questions\n\nWhich device events must leave the camera, and which topics represent them?\nDoes the requested business condition depend on a topic or a value inside the payload?\nWhere will any additional payload-based decision be implemented and reviewed?\nHow will the team verify that unrelated topics remain outside the publication selection?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends writing a two-column contract for publication selection and downstream interpretation before enabling automation.\n\nDescribe the desired input without starting from a wildcard. For a proposed pilot, select one required event topic and one nearby topic that should remain excluded. Write the operational reason for each selection. If the requirement refers to a payload value, put that condition in the consumer column and assign an owner to design it. Do not relabel the payload requirement as a bridge filter.\nApply the supported topic selection on a test device, then read the current publication configuration back. Compare that returned configuration with the intended topic list. Keep this evidence separate from proof that the MQTT client connects to its broker. An integration worksheet should give each of those checks its own result and owner.\nExercise representative included and excluded events through an authorized test arrangement. At the consumer, compare the received event topic and payload with the written contract before allowing a consequential action. Use a logging-only destination first where practical. Review unexpected traffic as a selection or interpretation problem, rather than widening filters until an application appears to work.\n\nVerification and evidence\nPreserve the intended topic list, returned bridge configuration, sanitized broker observations and consumer decision record. Use stable test labels so a reviewer can tell the deliberately excluded event from a missing required event. Record any payload logic as separately maintained application behavior.\nRepeat the proposed cases after changing topic filters, device software or the consumer’s event mapping. Include a requirement that cannot be expressed by topic selection alone and confirm that the design review routes it to the appropriate consumer work. These are proposed DSE verification steps, not a claim that any MQTT deployment or automation was tested.\nOfficial references\n\nMQTT Event Bridge — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: Choose the event topics at the Axis bridge, then place any required payload decision in a separately designed consumer.\n\n## Source fact: documented behavior\n\nThe [MQTT Event Bridge](https://developer.axis.com/vapix/network-video/mqtt-event-bridge/) documentation says event publications are enabled only after filters have been set.\n\nThose publication filters apply only to topics; payload filtering is not possible through that filter configuration.\n\nThe documented configuration-read operation returns the current event publication configuration.\n\n## What the source does not establish\n\nDo not assume that a topic filter expresses a condition on a field inside an event payload. Keep bridge selection separate from the broker connection checks and application rules. Require the actual event-topic contract for the device and integration before approving a topic pattern. Do not present the proposed consumer design as a feature supplied by this API.\n\n## Applicability questions\n\n- Which device events must leave the camera, and which topics represent them?\n\n- Does the requested business condition depend on a topic or a value inside the payload?\n\n- Where will any additional payload-based decision be implemented and reviewed?\n\n- How will the team verify that unrelated topics remain outside the publication selection?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends writing a two-column contract for publication selection and downstream interpretation before enabling automation.\n\n- Describe the desired input without starting from a wildcard. For a proposed pilot, select one required event topic and one nearby topic that should remain excluded. Write the operational reason for each selection. If the requirement refers to a payload value, put that condition in the consumer column and assign an owner to design it. Do not relabel the payload requirement as a bridge filter.\n\n- Apply the supported topic selection on a test device, then read the current publication configuration back. Compare that returned configuration with the intended topic list. Keep this evidence separate from proof that the MQTT client connects to its broker. An integration worksheet should give each of those checks its own result and owner.\n\n- Exercise representative included and excluded events through an authorized test arrangement. At the consumer, compare the received event topic and payload with the written contract before allowing a consequential action. Use a logging-only destination first where practical. Review unexpected traffic as a selection or interpretation problem, rather than widening filters until an application appears to work.\n\n## Verification and evidence\n\nPreserve the intended topic list, returned bridge configuration, sanitized broker observations and consumer decision record. Use stable test labels so a reviewer can tell the deliberately excluded event from a missing required event. Record any payload logic as separately maintained application behavior.\n\nRepeat the proposed cases after changing topic filters, device software or the consumer’s event mapping. Include a requirement that cannot be expressed by topic selection alone and confirm that the design review routes it to the appropriate consumer work. These are proposed DSE verification steps, not a claim that any MQTT deployment or automation was tested.\n\n## Official references\n\n- [MQTT Event Bridge](https://developer.axis.com/vapix/network-video/mqtt-event-bridge/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/", "url": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Keep Axis MQTT event publication filters at the topic layer", "item": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/#article", "identifier": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/", "url": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/", "headline": "Keep Axis MQTT event publication filters at the topic layer", "description": "Axis MQTT Event Bridge publication filters apply to event topics, not payload content.", "abstract": "Axis MQTT Event Bridge publication filters apply to event topics, not payload content. Design event selection at that documented boundary before connecting downstream automation.", "articleBody": "Bottom line: Choose the event topics at the Axis bridge, then place any required payload decision in a separately designed consumer.\nSource fact: documented behavior\nThe MQTT Event Bridge documentation says event publications are enabled only after filters have been set.\nThose publication filters apply only to topics; payload filtering is not possible through that filter configuration.\nThe documented configuration-read operation returns the current event publication configuration.\nWhat the source does not establish\nDo not assume that a topic filter expresses a condition on a field inside an event payload. Keep bridge selection separate from the broker connection checks and application rules. Require the actual event-topic contract for the device and integration before approving a topic pattern. Do not present the proposed consumer design as a feature supplied by this API.\nApplicability questions\n\nWhich device events must leave the camera, and which topics represent them?\nDoes the requested business condition depend on a topic or a value inside the payload?\nWhere will any additional payload-based decision be implemented and reviewed?\nHow will the team verify that unrelated topics remain outside the publication selection?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends writing a two-column contract for publication selection and downstream interpretation before enabling automation.\n\nDescribe the desired input without starting from a wildcard. For a proposed pilot, select one required event topic and one nearby topic that should remain excluded. Write the operational reason for each selection. If the requirement refers to a payload value, put that condition in the consumer column and assign an owner to design it. Do not relabel the payload requirement as a bridge filter.\nApply the supported topic selection on a test device, then read the current publication configuration back. Compare that returned configuration with the intended topic list. Keep this evidence separate from proof that the MQTT client connects to its broker. An integration worksheet should give each of those checks its own result and owner.\nExercise representative included and excluded events through an authorized test arrangement. At the consumer, compare the received event topic and payload with the written contract before allowing a consequential action. Use a logging-only destination first where practical. Review unexpected traffic as a selection or interpretation problem, rather than widening filters until an application appears to work.\n\nVerification and evidence\nPreserve the intended topic list, returned bridge configuration, sanitized broker observations and consumer decision record. Use stable test labels so a reviewer can tell the deliberately excluded event from a missing required event. Record any payload logic as separately maintained application behavior.\nRepeat the proposed cases after changing topic filters, device software or the consumer’s event mapping. Include a requirement that cannot be expressed by topic selection alone and confirm that the design review routes it to the appropriate consumer work. These are proposed DSE verification steps, not a claim that any MQTT deployment or automation was tested.\nOfficial references\n\nMQTT Event Bridge — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T00:10:28+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/keep-axis-mqtt-event-publication-filters-at-the-topic-layer/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Keep Axis MQTT event publication filters at the topic layer" }, "articleSection": [ "Networks & Infrastructure", "Video Surveillance" ], "keywords": [ "Networks & Infrastructure", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 518, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — MQTT Event Bridge", "url": "https://developer.axis.com/vapix/network-video/mqtt-event-bridge/" } } ] } }