Attackers no longer stop at the mailbox: files, links and sensitive data travel just as easily over chat. Collaboration Protection extends the ESG inspection engines — antivirus, URL sandboxing and data-loss prevention — to Microsoft Teams messages, covering one-to-one chats, group chats and channel posts.

Whenever a user of the protected Microsoft 365 tenant sends or edits a message, Microsoft notifies ESG in near-real-time. ESG retrieves the message, scans it on a dedicated processing lane that never competes with mail, and blocks it in place when it violates policy. Teams then replaces the message with a notice, and the sender can open a policy tip explaining exactly which rule was matched — turning a block into a teaching moment instead of a mystery. Attachments are scanned with the very same antivirus engines used for mail, links are analyzed in real time by LibraCyber URL sandboxing, and a self-contained DLP engine recognizes cloud and service credentials, API tokens, private keys, national identifiers, IBANs and credit-card numbers.

Collaboration Protection covers messages originating from the protected tenant and is configured per tenant under Integrations → Collaboration Protection, on top of an existing Microsoft 365 connector. Notifications are received on an isolated, dedicated web endpoint with its own TLS certificate and worker pool, kept separate from the administration interface. It is available as a licensed add-on.

Understanding why a message was flagged used to mean reading spam rules and authentication headers. Threat Breakdown turns that raw evidence into a single report that a security leader can act on, reachable from the detail page of any message classified as a threat.

The report opens with the threat verdict and a short, plain-language narrative of what the attack is trying to achieve, then walks through risk and spam confidence, sender identity, SPF, DKIM and DMARC results explained in words, the correlated signals that led to the verdict, the reconstructed attack chain stage by stage, the matched spam rules with their scores, DLP and payload status, and five prioritized recommended actions — from what the recipient should do to infrastructure containment, threat hunting and awareness training.

The threat narrative and the attack chain are generated by a language model that runs entirely on the appliance, as a hardened local service reachable only from the appliance itself: no message data ever leaves the box, and no external AI provider is involved. Every other panel is computed deterministically from the scan data and is displayed immediately, while the AI sections arrive a moment later. The feature is offered to enterprise customers and needs an appliance sized at the medium resource profile or above.

SAML 2.0 single sign-on brings access to the ESG console in line with the identity policy of the rest of your infrastructure: users authenticate against your identity provider, with its own multi-factor and conditional-access rules, instead of a separate local password. Each configuration is a trust relationship with one identity provider bound to one domain, and joins the per-domain authentication schemes ESG already supports alongside local, IMAP, POP3, LDAP, Microsoft 365 and Google Workspace.

ESG integrates seamlessly with Microsoft 365 / Entra ID, Google Workspace or any other SAML 2.0 identity provider: enter the provider identity, the sign-on address and its signing certificate, choose whether the login identifier comes from the response subject or from a named claim, and ESG surfaces the ready-to-use values to register on the provider side. Login and single logout are always started by ESG, so unsolicited responses are refused, and a signature is always required: turning assertion signing off simply forces response signing on, so an unsigned response can never be accepted.

Users are authenticated, not created: the SAML identity must resolve to a local account, provisioned by the domain directory synchronization or imported on first login when the provider is a generic one.