I have watched the same movie in a hundred SMB and mid-market environments: a new tool ships, plugs into one data source, paints everything Critical, and six months later the SOC mutes notifications. The tool is not evil. The model is wrong.

Dual-Strike XISEM is built on a different premise: evidence first, interpretation second, human decision third.

Alerts without evidence are opinions

When a SIEM rule fires on a single syslog line, the analyst inherits a hypothesis. When Threat Center fires after agent harvest + browsing category + Entra sign-in anomaly, the analyst inherits a story. Stories close faster and survive audit.

Collectors should not judge

Your EDR contains malware. Your email gateway blocked phish. Your browser extension saw AI tool usage. Each is a fact. None alone is a verdict. The platform’s job is correlation — not to replace the EDR console or become a mail filter.

That separation is why we insist agents and extensions prove rather than punish. Anti-Venom telemetry does not block the CEO’s browser because a model said so in the cloud — policy tiers and human-authored rules do, with session evidence visible in Browsing Insights.

Posture is a conversation, not a scoreboard

ASPIRE letter grades exist so a vCISO can sit with a client and say: “Security pillar dropped because EDR agent fell off three laptops — here they are.” Not: “Risk score 73.” Numbers without pillars are vanity.

Compliance is continuous, not annual panic

Framework mapping only hurts when it is a January spreadsheet. Tie controls to live evidence — patch state, identity disablement, extension coverage — and POA&M becomes a running backlog, not a fire drill before the auditor arrives.

MSPs win on narrative

Your clients buy outcomes: fewer incidents, faster recovery, audit confidence, browser visibility in the AI era. They do not buy “another integration.” Dual-Strike XISEM gives you one narrative across agent, browser, identity, EDR, and PSA — so your QBR slides tell a story, not a vendor laundry list.

Practical takeaway

Next time you evaluate or tune the stack:

1. Ask what evidence a detection requires before it pages someone

2. Ask which pillar moved when posture changes

3. Ask what closes the loop in PSA — not just what opens the alert

Evidence first is slower on day one and quieter on day thirty. That is the point.

Explore: Evidence doctrine infographic · Asset modal guide · dual-strike.com

Opinion piece — product architecture aligns with Dual-Strike XISEM doctrine published in Support wiki.

Dual-Strike XISEM UI philosophy: intelligence surfaces, not alert engines. The Asset modal is the clearest expression of that — a single-device (or single-identity) console where evidence converges before anyone opens a PSA ticket.

What opens when you click an asset

SurfacePurpose OverviewASPIRE grade, last seen, agent version, location class TimelineCorrelated events — agent, browser, identity, detections Extension HealthPer-browser status, last session, idle vs stale tiers MatricesPosture and CA evaluation snapshots ComplianceControl mappings tied to this asset’s evidence PivotsJump to user, related detections, browsing sessions

No tab is a standalone “warning light.” Each is evidence with context.

Investigation flow (example)

Scenario: Shadow AI detection on a sales laptop.

1. Threat Center → open detection → pivot to Asset modal

2. Timeline shows browser sessions to unsanctioned AI tool before EDR saw anything

3. Extension Health confirms Edge reporting (not a coverage gap)

4. Identity tab links Entra user for CA policy review

5. Create PSA ticket with evidence summary pre-filled

6. After remediation, close ticket — status syncs back

Who uses it

• SOC analysts — first stop after alert triage

• vCISOs — QBR screenshots (redact client names)

• Auditors — control evidence drill-down

• Engineers — agent version, harvest gaps, extension deploy issues

Capture tips for your runbooks

When documenting client procedures, screenshot Overview + Timeline with:

• Client display name redacted or replaced with “Demo Org”

• User emails hashed or removed

• Real hostnames replaced with CLIENT-WS-### pattern

We ship demo-style illustrations in this newsletter; your Substack posts can swap in live redacted captures.

Route: Inventory → any managed asset → opens modal

Related: ASPIRE scoring post · Browsing Insights field guide

Platform layer interprets harvester evidence — the modal never fabricates telemetry.

Endpoints do not float in vacuum. Network topology in Dual-Strike XISEM visualizes how assets connect: sites, VLANs, gateways, VPN paths, and discovered neighbors — correlated with agent inventory and identity sessions.

Route: /network · Support wiki → Network topology & discovery

Evidence sources for topology

SourceContribution XISEM agentLocal adapters, routes, DNS, peer discovery Network device infeedsFortinet, UniFi, Meraki-class integrations (per wiki) Identity locationOffice / home / unknown classification Manual site tagsClient org site definitions

Platform layer interprets harvester and integration evidence — it does not scan the network independently of collectors.

Operator use cases

1. Incident scope — “What subnet was this laptop on when detection fired?”

2. Segmentation audit — server VLAN reachable from guest Wi-Fi?

3. Asset context — Asset modal shows network attachment alongside ASPIRE

4. Compliance — network boundary controls (NIST SC family, PCI segmentation)

MSP workflow

1. Deploy agents to representative sites (HQ, branch, remote)

2. Connect firewall/switch integration where client owns supported gear

3. Review topology graph for orphan nodes (discovered but not managed)

4. Align orphan list with Inventory onboarding campaign

Limitations (honest)

• Cloud-only workloads may appear as identity + SaaS signals rather than L2 map

• Remote workers often show home/unknown location class — pair with Browsing Insights

• Discovery depth depends on agent and integration coverage — not a replacement for dedicated NDR (roadmap items public on wiki)

Related: ASPIRE Environment pillar · CVE correlation post

No internal scan schedules or credential storage details — configure integrations in-console.

Dual-Strike XISEM Threat Intelligence integrations ingest IOC feeds (hashes, domains, IPs, URLs) and match them against agent harvests, DNS logs, browsing sessions, and EDR exports. Matches elevate in Threat Center and can trigger COBRA² rules.

Route: Settings → Threat Intelligence · Support wiki → Threat intelligence feeds

Feed types

TypeExample sources (wiki index) Commercial TIPartner feeds via API Open sourceSTIX/TAXII compatible lists ISAC / sectorClient-specific sharing agreements InternalYour own block lists from prior incidents

Match surfaces

• Browsing Insights — domain/URL reputation hits

• Asset modal — file hash on disk vs. feed

• Network — DNS query to known C2 domain

• Email — attachment hash from Proofpoint/M365 path

Tuning for false positives

1. Start feeds in alert-only mode per client

2. Require 2-of-N correlation for auto-ticket (e.g., DNS hit + process execution)

3. Exclude known CDN domains via MSP baseline exception list

4. Review weekly top matched IOCs — retire stale entries

MSP differentiator

Most SMB clients cannot operate a TI platform. You operationalize feeds once at MSP tier, inherit downstream to clients with appropriate data sharing contracts.

Compliance angle

Threat intelligence usage satisfies monitoring and analysis controls in NIST, SOC 2, and CMMC when documented with feed source, update cadence, and match response procedures.

Related: COBRA² guide · Email security layer · Threat Center

Feed credentials stored per integration policy — never publish API keys in newsletters.

Anti-Venom Secure Access applies policy from a six-tier hierarchy. Higher specificity wins. MSPs managing dozens of clients rely on this model to ship one baseline and per-client exceptions without redeploying extensions.

The six tiers (high → low precedence)

1. Client org exception — single-customer rule (e.g., allow industry portal)

2. Client org policy — default browser posture for that customer

3. MSP org override — your standard across all clients unless excepted

4. Platform template — Dual-Strike published baselines (AI tools, risky categories)

5. Agent local relay — offline/cache path when using LocalApi-first mode

6. Extension built-in safe defaults — fail-closed for unknown categories

Exact tier names in-console may vary slightly — precedence order is what matters.

What policies control

CategoryExample AI toolsAllow Copilot, warn on consumer ChatGPT Risky domainsBlock phishing tiers, warn on new domains SaaS catalogSanctioned vs. shadow IT labels Business hoursStricter rules outside 9–5 local TelemetrySession upload via agent relay vs. direct

Deployment flow (recap)

1. Agent on endpoint (MSI or RMM)

2. Extension from browser store (Edge GA highlighted in prior post)

3. Policy publish in console — extensions poll on interval

4. Browsing Insights validates sessions and categories

5. COBRA² consumes categories for detections

MSP pattern: golden template

1. Define MSP tier once — AI warn, risky block, SaaS tag

2. Clone to new client org on onboarding

3. Add client exceptions only for documented business apps

4. Review Browsing Insights top domains quarterly — promote shadow IT to sanctioned or block

Settings: Browser Extension · Insights: /browsing-insights

Downloads: dual-strike.com/downloads

Prefer agent relay at scale — reduces per-device cloud chatter (public architecture guidance only).

Tier 2 analysts lose hours context-switching between EDR, Entra, PSA, and spreadsheet exports. The Pivot Analyst Workbench (public name in product wiki) is Dual-Strike XISEM’s structured hunting layer: start from any evidence object and follow platform-defined pivots without writing queries.

Route: Asset modal → Pivot · Threat Center → Investigate · Support wiki → Pivot analyst workbench

Entry points

Start fromCommon pivots Browser sessionUser, device, related detections, domain prevalence Entra sign-inDevice, location class, mailbox rules, COBRA hits DetectionAll contributing signals, affected assets, PSA ticket File hashOther assets with hash, TI feed match, process tree (EDR) CVEAffected assets, patch status, network exposure

Workbench vs. Investigations

• Workbench — exploratory, ephemeral trail while analyst thinks

• Investigations — persistent case with notes and assignee

Promote workbench trail to Investigation when you know you have a case.

MSP hunting playbooks (public)

Shadow AI hunt

1. Browsing Insights → filter AI category → open session

2. Pivot user → all AI domains 30d

3. Pivot detections → COBRA shadow AI rules

4. Create Investigation + PSA ticket

BEC hunt

1. Email integration → suspicious rule change

2. Pivot identity → sign-ins + mailbox

3. Pivot browsing → OAuth grants

4. Escalate Critical if dual control failed

Training new analysts

Workbench teaches correlation paths native to Dual-Strike XISEM — faster ramp than teaching five vendor consoles. Pair with COBRA² guide and Asset modal post for onboarding curriculum.

Limits (honest)

• Pivots require infeed coverage — no Entra pivots without GDAP

• Historical depth follows retention policy — long hunts may need exported reports

• Workbench does not replace EDR process graph for deep malware analysis — pivot into vendor console when containment needed

Related: Investigations workflow · Browsing Insights · Threat intelligence feeds

Workbench pivot catalog expands per release — in-console menu is authoritative.

Compliance assessments fail when gaps live in email threads. Dual-Strike XISEM POA&M (Plan of Action & Milestones) generation turns compliance gaps, detection findings, and manual auditor notes into tracked remediation items with owners, due dates, and evidence of closure.

Route: Compliance → POA&M · Support wiki → Compliance getting started

POA&M item anatomy

FieldPurpose Control referenceFramework + control ID Gap descriptionPlain language SeverityCritical → low OwnerClient or MSP assignee Due dateMilestone tracking Evidence of closureLinked detection resolved, patch proof, config screenshot PSA ticketWhen outfeed enabled

Generation sources

1. Automated — compliance scan finds partial/not met control

2. Detection-promoted — Critical COBRA finding → POA&M row

3. Manual — auditor adds item during assessment

4. Bulk import — spreadsheet template (in-console)

Monthly vCISO rhythm

1. Export open POA&M PDF for client steering committee

2. Sort overdue items → PSA escalation

3. Close items only with evidence attachment (agent harvest, report snapshot)

4. Trend open count down — executive binder widget

Auditor conversation

Auditors want traceability:

> “Show me control AC-2 partial — what opened it, who owns it, what proved closure.”

POA&M row links satisfy that without rebuilding binders each visit.

Related: Compliance mapping 100+ frameworks · Reports · Client portal

POA&M exports redact internal analyst notes marked MSP-private when configured.

Compliance frameworks ask whether critical system files changed. Traditional FIM agents are heavy, noisy, and often deployed on servers only.

Dual-Strike XISEM 8.8.0 closes the loop: agent collection → platform ingest → Threat Center File Integrity tab → alert path for high/critical changes.

What the agent watches (Windows default)

When WatchPaths is empty, the Windows agent hashes on each security harvest (~15 min):

• C:\Windows\System32\config\SAM

• C:\Windows\System32\config\SECURITY

• C:\Windows\System32\config\SYSTEM

• C:\Windows\System32\drivers\etc\hosts

Configurable via Agent:FileIntegrity in agent settings.

What analysts see

• Threat Center → File Integrity — baselines, changes, analyst explainer copy

• High/critical path changes continue through existing alert logic

• Compliance mapping for PCI-DSS, HIPAA, SOC 2-style controls where FIM evidence applies

Deploy checklist (public)

1. Upgrade to Dual-Strike XISEM Agent 8.8.0 GA line when promoted in your channel

2. Confirm one security harvest cycle completes

3. Open File Integrity — expect four tracked files per Windows endpoint at baseline

Downloads: dual-strike.com/downloads

Ship when 8.8.0 GA is your fleet standard — adjust version callout if publishing before GA promotion.

Every client leadership team got the memo: “We need an AI policy.”

Few got the telemetry: “Who used which AI tool, from which device, with what data exposure risk?”

Dual-Strike XISEM classifies AI tool sessions in Anti-Venom browsing telemetry and surfaces them in Browsing Insights and COBRA² detection paths.

What we detect (conceptually)

• Sessions to known AI SaaS domains (ChatGPT, Microsoft Copilot, Claude, Gemini, etc.)

• Duration and frequency — not just “someone visited once”

• Correlation with identity, device posture, and location class

• Optional COBRA rules for unsanctioned AI on regulated endpoints

Why agent + extension matter

Browser-only DLP misses context. Anti-Venom paired with the XISEM Agent gives:

• Authenticated user correlation where identity infeeds exist

• Policy enforcement paths (warn / block / watermark) when you move from learning to enforce

• Agent relay for scalable ingest

Operator playbook

1. Roll extension in learning mode — collect two weeks of AI usage

2. Browsing Insights → filter AI tool sessions → export talking points for client steering committee

3. Define sanctioned vs unsanctioned tools in browser policy

4. Enable COBRA detection for high-risk combinations (e.g., AI tool + file-share category same session window)

The conversation shift

Instead of “We banned AI,” you bring “Here’s who used what, here’s the policy tier, here’s what we blocked this month with evidence.”

That’s how security teams stay credible while the business adopts AI anyway.

Start: Anti-Venom rollout → Browsing Insights → dual-strike.com/downloads

AI domain classification updates with threat intel and SaaS catalogs — confirm categories in-console for your scope.

“Conditional Access” became synonymous with Microsoft Entra. But access decisions in real organizations depend on more than IdP signals: where the device is, what the endpoint posture is, whether the browser extension attests, what EDR last saw.

Dual-Strike XISEM Conditional Access intelligence is a platform-level abstraction — client-org scoped, not tied to a single vendor console.

What it evaluates

Policies express scope (asset types, identity types), conditions (location class, risk tier, posture signals), and actions (restrict, block, step-up, isolate, monitor).

Default templates include patterns operators recognize:

• Block privileged access from unknown locations

• Step-up auth when identity appears from home network with drift

• Read-only posture during geo anomalies

Evaluations are logged for audit — auditable outcomes, not silent blocks in an agent.

Where you see it

• Compliance console → Conditional Access tab

• Asset modal → correlated CA posture alongside evidence timelines

• MIP overview → CAA / attestation coverage rollup

Why MSPs care

Clients ask: “Are we zero trust?” You need a answer that doesn’t require exporting Entra CA to a spreadsheet and hand-waving device trust.

XISEM correlates harvester evidence (location, agent health, extension attestation, identity) into policy evaluations your analysts can explain in a QBR — and map to compliance frameworks already in the platform.

Not enforcement — intelligence

Dual-Strike XISEM does not replace Entra CA enforcement at the IdP. It informs decisions: detections, investigations, POA&M items, and client reporting.

That separation matters: the platform stays evidence-driven; enforcement stays where admins already configure it.

Explore: Compliance → Conditional Access · dual-strike.com

Policy templates evolve with releases — use in-console descriptions as ground truth.

We sell a platform. This post isn’t a pitch — it’s a pattern we see in every mature MSP and internal IT org:

Tool count correlates weakly with outcomes. Integration depth correlates strongly.

The sprawl trap

A typical mid-market client stack in 2026:

• RMM + PSA

• M365 + Entra

• EDR

• Email security

• Backup

• Maybe a SIEM someone bought and never finished

• Maybe a “browser security” SKU that nobody checks

Each tool has its own alert language, its own asset ID, its own ticket queue. Technicians become human ETL pipelines: copy hostname from A, paste into B, hope the user email matches.

Security doesn’t fail because you lack a dashboard. It fails because no dashboard owns the narrative.

What “working together” actually means

Not “we have an API.” Working together means:

1. One asset identity — serial, Entra device ID, agent ID, and PSA company map to the same row

2. One severity story — detection in XISEM → ticket in ConnectWise → close syncs back

3. One identity story — leaver in HR → MIP lifecycle → session revoke + license review

4. One browsing story — risky SaaS in Anti-Venom → Browsing Insights → COBRA rule → client QBR slide

When those chains exist, junior techs execute playbooks. When they don’t, senior people burn out triaging contradictions.

Posture is a team sport

We built Dual-Strike XISEM around evidence doctrine: collectors prove facts; the platform interprets; humans decide.

That only works if:

• Agents report consistently (patch the straggler before debating SIEM rules)

• Extensions are store-deployed and agent-paired (not ghost 6.x profiles)

• Identity infeeds are connected before you claim “zero trust”

• PSA tickets close when the incident closes — or metrics lie

The organizations that win treat integrations as operating procedures, not checkboxes on a sales deck.

A practical Monday exercise

Pick one client. Trace one user through:

• Entra sign-in → asset in XISEM → browsing session → open detection → PSA ticket

Where does the chain break? Fix that before buying tool #12.

We’ll keep shipping releases (8.7.x, MIP, PSA paths, Edge store). The teams that extract value will be the ones that wire them — not the ones with the longest vendor list.

If you want the platform side of that wiring: dual-strike.com/demo

You have EDR. You have email security. You still don’t know which SaaS apps, AI tools, or risky domains your users hit in the browser until something shows up on a credit report.

Browsing Insights is the Dual-Strike XISEM console for web session telemetry from Anti-Venom Secure Access — duration, categories, AI classification, risky flags, business-hours context, and investigation pivots.

Route: /browsing-insights

What you see

ViewOperator use Sessions over timeVolume trends — did rollout work? Top domains / SaaSShadow IT and unsanctioned apps AI tool usageChatGPT, Copilot, Claude, etc. Risky / blockedPolicy and reputation hits By user / by deviceInvestigation starting points Extension HealthWhich browsers report, which don’t

Data flows from Anti-Venom (direct cloud or agent relay — preferred at scale).

How it fits the stack

1. Deploy Dual-Strike XISEM Agent on the endpoint

2. Deploy Anti-Venom (Chrome, Edge, or Firefox — store GA on 8.7.x)

3. Publish browser policy in Settings → Browser Extension

4. Open Browsing Insights — filter by client, user, domain, time range

No manual Supabase URLs for end users. Production posture is agent-gated.

Recent improvements (8.7.0.17 platform)

• Reliable session loading at MSP multi-client scope

• 24-hour default time window (better Monday reviews)

• Extension Health weekend grace — spare laptops aren’t false “not detected” alarms

Tie-in to detections

Browser events feed COBRA² rules: shadow AI, DLP-class categories, exfil patterns. Turn on browsing first; tune detections second.

Start here

1. Pick one pilot client with agent + extension deployed

2. Confirm Extension Health shows green/idle — not “not detected”

3. Review top domains and AI sessions for a week

4. Add one COBRA rule for your highest-risk category

Docs path: Support wiki → Anti-Venom & Browsing Insights · dual-strike.com/downloads

Retention follows platform policy — aggregate reporting for large fleets should use rollups where available.

Your SOC finds something real. Then someone copies a title into ConnectWise. Then the ticket closes in the PSA but stays open in the SIEM. Then nobody trusts either system.

Dual-Strike XISEM PSA integrations exist to break that loop: native ticket create, bidirectional close sync, and client mapping from the same console where detections and alerts already live.

What’s supported today

Configure at /integrations/psa (MSP credentials + per-client company mapping):

PlatformNative API / path ConnectWise ManageREST AutotaskREST Syncro MSPREST Halo PSAOAuth REST SuperOpsGraphQL NinjaOneOAuth REST FreshserviceREST ZendeskREST ServiceNowREST Jira Service ManagementAtlassian REST Console (console.com)Webhook playbook N-able N-centralCustom PSA webhook Custom webhookJSON POST to your middleware

What gets ticketed

You choose rules — not a firehose:

• COBRA² detections & threats (primary path from the Threats console)

• Alerts (with optional skip when already backed by a detection — avoids duplicates)

• High/critical security events

• CVE correlation hits

• OSINT threat-actor overlap with client telemetry

• Manual “Create Ticket” from any investigation

Rate limits (max tickets per hour/day) keep noisy environments from spamming the PSA.

Bidirectional sync

When a ticket closes in the PSA, XISEM can resolve the linked detection/alert — and when XISEM resolves, the PSA ticket updates too. Scheduled sync keeps status from drifting for days.

RMM context (not just tickets)

Beyond PSA, Dual-Strike XISEM ingests from SuperOps, NinjaOne, SentinelOne (MSP site maps), Hudu, Huntress, DNSFilter, and the XISEM agent fleet itself — so asset identity in the console matches how you already organize clients in the RMM.

Infeeds & integrations live at /infeeds and /msp-tenants depending on vendor (MSP vs client scope).

Monday-morning setup (15-minute version)

1. PSA Integrations → pick your PSA tab → enter MSP API credentials → Test

2. Client Mapping → link each PSA company to a XISEM client

3. Ticket rules → enable detections + alerts at your minimum severity

4. Fire a test detection in a lab client → confirm ticket lands in the right queue

Why this post belongs in a security newsletter

Integrations aren’t checkbox features. They’re posture multipliers: the same signal that drives compliance evidence should drive work your technicians already do — in the tool they already live in.

Explore integrations: dual-strike.com · console PSA Integrations

Exact tab labels and vendor OAuth flows evolve — use in-console setup wizards as ground truth.

Identity programs usually stop at people.

Meanwhile, the breach story moved to non-human identities (NHIs) — service principals, API keys, OAuth consents, workload identities, automation accounts, and “temporary” integration users that never left.

Dual-Strike XISEM Managed Identity Provider (MIP) is our answer: one console for joiner-mover-leaver, privileged access, access reviews, ITDR, and NHI governance — without replacing Microsoft Entra, Okta, or Google Workspace. We correlate and govern across them.

What MIP is (one sentence)

MIP is identity governance and ITDR posture for scoped clients — lifecycle rollups, risk signals, certifications, and evidence bound to frameworks — in /identity/mip.

The pillars operators care about

Identity lifecycle (JML)

Joiner → Mover → Leaver state machine with visibility into who’s active, suspended, or still licensed after offboarding. Stale leavers are where auditors and attackers overlap.

SCIM 2.0 provisioning

Bidirectional connectors for Entra ID, Okta, and Google Workspace. One MIP fabric; multiple directories.

Privileged Identity Management (JIT)

Just-in-time elevation with ticket-bound approval, time limits, and automatic revocation — standing privilege trending toward zero.

Access reviews & certification

Quarterly (or custom) campaigns: approve, deny, delegate. Decisions land in a tamper-evident audit warehouse — not a spreadsheet.

ITDR — identity threat detection

Detect-first, recommend-first signals: token theft patterns, OAuth consent abuse, MFA fatigue, dormant accounts, weak-MFA exposure — with analyst-ready actions (session revoke, MFA reset, role drop).

OAuth & SaaS app risk

Continuous discovery of consented apps and third-party connectors — publisher trust, scope risk, and footprint in one tier.

Role mining & Segregation of Duties

Jaccard clustering suggests roles from entitlement patterns; SoD rule packs flag toxic combinations (finance vs IT admin vs audit).

NHI governance — the part most “IG” products hand-wave

Non-Human Identity governance in MIP covers:

NHI typeWhat MIP tracks Service principals & app registrationsOwnership, last use, excessive scopes API keys & secretsRotation age, stale credentials OAuth grants & workload identitiesOrphan detection, consent drift Automation / integration accountsDormant flags, privilege weight

Why it matters: NHIs don’t show up in HR offboarding. They accumulate in Azure, SaaS marketplaces, and PSA webhooks — until something exfiltrates data with a key that “was always there.”

MIP gives NHIs inventory, risk context, and audit lineage next to human identities — so your access review program isn’t blind to half the attack surface.

Compliance binding (without a separate GRC project)

MIP actions map to evidence for NIST 800-53, CMMC 2.0, SOC 2, and ISO 27001 — AC, IA, AU, and IR families — auto-bound where the platform observes identity events.

Who this is for

• MSPs/MSSPs standardizing identity posture across clients

• vCISOs who need one pane for lifecycle + ITDR + certification

• Regulated clients (defense, finance, healthcare) where NHI and SoD are examiner questions — not trivia

Getting started

1. Connect identity infeeds (Microsoft GDAP / Entra, Okta, Google Workspace, Petra ITDR where used)

2. Open Identity (MIP) at client scope — review lifecycle outliers on the overview rollup

3. Enable access review campaigns and NHI inventory for high-risk clients first

Learn more: dual-strike.com · request a Managed Identity Provider demo

MIP detects and recommends; your IdP remains authoritative for authentication. Dual-Strike XISEM is the intelligence and policy layer — not a replacement directory.

8.7.0.17 is now the current General Availability line for Dual-Strike XISEM Agent, Anti-Venom Secure Access (Chrome, Edge, Firefox), and the platform console — one SemVer, one fleet story.

If you’ve been waiting for “store-primary Edge + stable browsing dashboards,” this is the build to standardize on.

Highlights

Anti-Venom on all major desktop browsers (store GA)

• Chrome, Edge, and Firefox public store builds at 8.7.0.17

• Enterprise Edge deployments benefit from store-trust and simplified Intune/Edge policy (see our Edge announcement post)

• Agent bundles and RMM packages updated on dual-strike.com/downloads

Browsing Insights — data you can trust

Operators told us the hard part wasn’t collecting sessions — it was seeing them in the console when scoped to an MSP with many clients.

8.7.0.17 platform improvements:

• Browsing session views load reliably at MSP and client scope (no more empty “By Device / By User” when telemetry exists)

• Default time range widened to 24 hours so Monday-morning reviews include Friday activity

• Clear error banner when session load fails — with retry — instead of silent zeros

Use Browsing Insights for SaaS discovery, AI-tool usage, risky domains, and investigation pivots per user or device.

Extension Health — truthful, not noisy

Spare laptops. Conference room PCs. “Nobody’s logged in since Thursday.”

Extension Health now distinguishes:

• Healthy / idle extension telemetry (including weekend-scale agent check-ins)

• Actionable “extension not detected” — agent active in the last 24 hours, but no Chrome/Firefox/Edge extension reporting

• Endpoints idle 24–72 hours — not screamed as failures

You get fewer false alarms and a shorter list of devices that actually need a store install or policy push.

Security posture & ASPIRE scoring

Improvements to extension-attested posture and ASPIRE alignment — so Conditional Access and browsing evidence show up consistently in the asset narrative analysts already use (not a separate “mystery zero”).

Agent delivery

• Windows MSI and Linux installer scripts on the downloads CDN

• OTA/update checks point at the current GA artifact (upgrade path documented on Downloads)

Who should upgrade?

RoleAction MSP operatorRoll 8.7.0.17 agent + store extensions via RMM; verify Extension Health AnalystRe-open Browsing Insights after platform refresh — confirm session counts Client adminNo action if your MSP manages agents; otherwise pull MSI from Downloads

Upgrade path

1. Deploy Dual-Strike XISEM Agent 8.7.0.17 (MSI or your RMM package)

2. Confirm Anti-Venom 8.7.0.17 on Chrome / Edge / Firefox (store or enterprise policy)

3. Hard-refresh the console — validate Browsing Insights and Extension Health

Get the build: dual-strike.com/downloads

Platform-only updates apply on login — no agent install required for Browsing Insights and Extension Health UI fixes.

Microsoft Edge is the default browser in a huge slice of the market: Entra-joined laptops, VDI pools, and “we standardized on Edge for compliance” shops. If your secure browsing policy only lived in Chrome, you were always one default-browser setting away from a gap.

That gap closes today.

Anti-Venom Secure Access — the Dual-Strike XISEM browser extension — is available on the Microsoft Edge Add-ons store, alongside Chrome Web Store and Firefox Add-ons, aligned on the current 8.7.x release line.

What Anti-Venom does (in plain language)

Anti-Venom is not a generic “web filter.” It’s the browser-side enforcement and telemetry layer for Dual-Strike XISEM:

• Session visibility — domains, duration, AI-tool usage, risky categories (feeds Browsing Insights)

• Policy enforcement — allow, warn, and block with verdict watermarks your analysts can explain

• Agent-gated posture — production deployments pair the extension with the Dual-Strike XISEM Agent on the same endpoint so policy and telemetry stay under your control (LocalApi / agent relay paths — not ad-hoc user configuration)

End users don’t paste API keys. MSPs deploy agent + extension through RMM, Intune, or store policy — the same playbook you already use for Chrome.

Why Edge store matters

Enterprise Edge deployments often block sideloads and unsigned CRX paths. Store distribution means:

• Fewer “organization blocked this extension” tickets

• Cleaner alignment with Intune / Edge management policies

• One version line with Chrome and Firefox — no shadow 6.x installs fighting your 8.7 fleet

What to do

1. Confirm Dual-Strike XISEM Agent 8.7.x is deployed to the endpoint (extension expects the agent companion).

2. Deploy Anti-Venom from the Edge Add-ons listing (or your existing enterprise force-install policy pointing at store IDs).

3. Publish browser policy in Settings → Browser Extension; allow ~15 minutes for refresh.

4. Open Browsing Insights and Extension Health to confirm check-ins.

Downloads & store links: dual-strike.com/downloads

Questions about monitor vs protect modes or learning vs enforce? That’s a great follow-up post — reply here and we’ll cover deployment tiers next.

If you run an MSP, MSSP, or internal security team, you already have too many dashboards. What you rarely get is a straight answer to three questions:

1. What actually shipped?

2. Does it matter to my clients?

3. What do I do Monday morning?

That’s what this publication is for.

Dual-Strike XISEM is our security intelligence and policy platform: evidence from agents, browsers, identity, and integrations — correlated into posture, detections, compliance, and response. We build the agent, the Anti-Venom Secure Access browser extension, and the console on one version line so your fleet doesn’t drift.

Here’s what you’ll see here:

• Release notes you can forward to clients (8.7.x, extension store updates, platform UI)

• Capability deep-dives (Managed Identity Provider, Browsing Insights, PSA ticketing)

• Integration announcements (RMM/PSA, EDR, identity infeeds)

• Occasional essays on why tool sprawl fails — and what “working together” actually looks like

We won’t publish internal runbooks, infrastructure gossip, or “we fixed a query.” We will publish what changes your operational reality.

Get started: dual-strike.com · Downloads · Request a demo

Subscribe so you don’t have to watch GitHub.

— The Dual-Strike team

If you run an MSP, MSSP, or internal security team, you already have too many dashboards. What you rarely get is a straight answer to three questions:

1. What actually shipped?

2. Does it matter to my clients?

3. What do I do Monday morning?

That’s what this publication is for.

Dual-Strike XISEM is our security intelligence and policy platform: evidence from agents, browsers, identity, and integrations — correlated into posture, detections, compliance, and response. We build the agent, the Anti-Venom Secure Access browser extension, and the console on one version line so your fleet doesn’t drift.

Here’s what you’ll see here:

• Release notes you can forward to clients (8.7.x, extension store updates, platform UI)

• Capability deep-dives (Managed Identity Provider, Browsing Insights, PSA ticketing)

• Integration announcements (RMM/PSA, EDR, identity infeeds)

• Occasional essays on why tool sprawl fails — and what “working together” actually looks like

We won’t publish internal runbooks, infrastructure gossip, or “we fixed a query.” We will publish what changes your operational reality.

Get started: dual-strike.com · Downloads · Request a demo

Subscribe so you don’t have to watch GitHub.

— The Dual-Strike team