News

Security Labels & MUC Rooms

6th July 2026 Steve Kille Blog

About the author

Steve Kille has worked for many years on open standards for Messaging, XMPP, Directory, Security, and HF Radio. He has worked on CCITT, IETF, XSF, and NATO standards (currently editing STANAG 5066), which have been implemented by Isode.

He is also Isode’s CEO

Security Labels & MUC Rooms

Security Labels are increasingly important for XMPP Chat, as they are a central building block of Data-Centric Security (DCS). Detailed notes are provided in the Isode white paper, XMPP, and Security Labels.

Security Labels for 1:1 chat are straightforward. Setups for MUC (Multi-User Chat) Rooms are more complicated, and I’ve encountered confused and incorrect thinking in several places. This post is intended as a precis of the key points in the white paper.

The key rule to follow is that Security Labels are always checked against Security Clearances; you do not check labels against labels. Security Labels are associated with information (e.g., messages or documents), while Security Clearances are typically associated with Users (controlling user access) or Channels (controlling where information flows).

For XMPP, the information is “messages” with a Security Label on each message. For 1:1 chat, this works simply, with access controlled by the recipient’s security clearance.

It gets more complex with MUC rooms. People note the security signs (e.g., UK SECRET) used in physical meeting rooms and jump to the incorrect conclusion that MUC rooms need labels and that you assign a label to a MUC room like you would a physical room. This approach doesn’t work because a MUC room is a channel and not an information object. The fundamental approach of labeling messages as the basic information object remains.

MUC rooms need three controls.

  1. Clearance. This reflects that a MUC room is a channel, and this clearance controls which messages can pass through. The sign on the physical room is also a clearance (in the example, the sign generally means “up to UK SECRET”). Note that this MUC Clearance check is additional to user clearance checks. It is possible for messages to be allowed through a MUC room and then not delivered to a MUC room participant.
  2. Label. This is checked against user clearances to control access to the room (there is a good, worked example of this for cross-domain operation in STANAG 5663). This can be a helpful control.
  3. Default Label. This label will be the default used in the MUC room and will typically appear as a banner at the top of the MUC room. This defines that unless otherwise stated, all messages sent in this room will be classified at the default security label level.

This gives a powerful and flexible framework.

If a simpler experience is required, the framework can be used in a simpler way. To achieve the “Security Sign” effect, you can assign the room a clearance that matches only a single label. Then Label and Default Label are set to this single label.

MUC rooms can be complex, but they don’t have to be complicated if you follow the key processes set out above. If you’d like to learn more about XMPP & Security Labels, you can read through the white paper linked above.