The advisory came 47 days late and your logs last 30

Today is the deadline CISA gave federal agencies to close the BeyondTrust Remote Support flaw. If you run that product, you already know you have to patch. What almost nobody is looking at is the other date in the case: the first known use of the flaw was 29 August, and the advisory came out on 15 October. Forty-seven days. The question that comes after the patch is whether you can look that far back.

What happened, with the dates on it

CVE-2026-102764 is an improper origin validation flaw in an internal messaging component of BeyondTrust Remote Support (the product formerly called Bomgar): that component did not properly check where a message came from, which lets an unauthenticated attacker perform file operations on the appliance. It scores 9.3 out of 10 on CVSS 4.0 and affects version 26.2.3 and everything before it; the fix, BT26-05-RS, installs on top of the 24.3.1 to 26.2.3 branches, so anyone below that has to upgrade before they can patch.

The public timeline, in order: on 29 August 2026 the first exploitation is observed — one instance hosted by the vendor itself and one customer's self-hosted appliance; BeyondTrust detects the incident on its hosted instance on 28 September, during proactive hunting, and reproduces the entry vector that same day; it has a patch built by 30 September, tests it and closes further paths before shipping BT26-05-RS on 8 October, and by the 9th has applied it to all its cloud instances; on 15 October it publishes the advisory and the CVE; on the 16th CISA adds it to the known exploited vulnerabilities catalogue with a deadline of today, 19 October, for US federal agencies. Google Threat Intelligence and Mandiant attribute the exploitation to an espionage group they call ARMORY CASTLE (formerly UNC5221), and describe what followed once inside: escalation to root, a web shell to stay in, credential harvesting, changes to access controls and lateral movement into other systems. That split is worth reading properly before anyone uses it in a meeting: of the 47 days between first exploitation and advisory, for thirty of them the vendor did not know the flaw existed. The delay was not sitting in a drawer; nobody had seen it.

None of that is unusual. A remote support product is, by design, a privileged piece sitting over half the world's machines — we wrote about that particular surface in the remote support tool is a privileged door — and CISA's catalogue arriving after weeks of real-world use is not new either: the catalogue is an acknowledgement of receipt, not an alarm, and we argued it in full in the KEV catalogue is an acknowledgement of receipt, not an alarm. What is interesting here is something else.

The day-48 question

The day an advisory like this lands, the work splits in two. The first half is familiar and bounded: inventory, patch, rotate credentials, review access. It is the half everybody knows how to do and the one that makes the headlines. The second half is a single sentence, and it always arrives from the board or from a customer: "and us — were we caught in it?".

The patch does not answer that question. The log does, and the log has an expiry date set months ago, usually by default and almost never by a person. If the window you can query starts on 19 September, then 29 August does not exist: it is not that you see nothing suspicious, it is that you see nothing at all. And answering "no activity on record" when the truth is "I have no data for those dates" is, with respect, lying in a report.

How far back you can look, out of the box

These are the defaults of the platforms our customers use most, as published by Microsoft. They are not opinions or estimates: they are in the documentation.

Look at how that falls: the thing most people go to when there is a scare — who signed in, from where, with which application — is precisely the one that lasts least. Thirty days cover the previous month and nothing more. In this specific case, the first known use of the flaw fell seventeen days outside that window on the day the advisory was published: counted back from 15 October, the window started on 15 September.

The line that settles it: retention is not retroactive

Here is the part that genuinely hurts, and Microsoft's documentation says it without hedging: retention changes are not retroactive. If you upgrade from Free to P1 today, you only get back what is still inside the seven days; anything already expired cannot be recovered unless it was previously archived. With Purview's long-retention policies, Microsoft says it explicitly of the ten-year one — it retains nothing generated before the policy was created — and warns generally that a change of policy does not affect what is already recorded. And on Defender's streaming API the note is just as clear: retention starts on the first day you enable it.

Which is to say: the ability to investigate an incident you do not yet know about is bought before you know about it. It is the same kind of decision as a backup, and it has the same unpleasant property: the day you need it, you can no longer make it.

And the appliance's own log is worth least of all

One uncomfortable detail remains. In this case the attacker reached root on the appliance and tampered with access controls. The logs living inside that same machine — and on an appliance they usually do, rotating every few days for want of disk — are, from that moment on, the least trustworthy evidence you have: whoever owns the machine owns what the machine writes. Hence the boring old advice: the logs of an exposed box leave the box, to somewhere with different credentials and a different owner. A remote syslog, a collector on your network, whatever SIEM you already have. It costs an afternoon and changes nothing day to day, until the morning you have to look back.

The five day-48 checks

This is what we do when an advisory like this comes in, and it can be done today without buying anything:

When NOT to buy more retention

Conflict of interest up front: we sell managed EDR/MDR and compliance and continuity services, so when we say "keep more logs" we are talking about something we bill for. Which is exactly why it is worth saying where we stop.

Ten years of logs nobody queries is not security, it is a warehouse with a monthly invoice. If you have to choose — and in a small company you almost always do — the order we argue for is: first make the logs leave the machine that writes them; then have somebody look at them who knows what counts as odd in your particular house; and only then stretch the window. Thirty days properly shipped off-box and watched are worth more than a year parked somewhere nobody remembers the password to. Our internal rule on monitoring is just that: an alert that obliges nobody to do anything gets deleted, because alert fatigue is the most effective way we know of not seeing what matters.

The usual axis, applied here: failure is inevitable, an outage is a design decision. That a vendor has a bad day and a well-resourced group makes use of it for forty-seven days before the vendor published it is not in your hands. What is in your hands is whether, on the day you find out, you can answer with data or only with a shrug. That difference is bought months earlier, or not at all.

Sources and method: the flaw details (CVE-2026-102764, CVSS 4.0 of 9.3, improper origin validation, versions 26.2.3 and earlier, BT26-05-RS patch) and the exploitation timeline from 29 August 2026 come from BeyondTrust's BT26-05 advisory and the analysis by Google Threat Intelligence Group and Mandiant, as reported by the trade press — beyondtrust.com and thehackernews.com. The KEV listing on 16 October and the 19 October deadline for federal agencies come from CISA — cisa.gov. The attribution to ARMORY CASTLE is Google/Mandiant's, not ours, and we report it as what it is: the reading of those who investigated the case. The retention figures come from Microsoft's documentation: Entra ID (7 days on Free, 30 on P1 and P2; risk reports 7/30/90) and the warning that retention is not retroactive — learn.microsoft.com; Purview Audit (180 days on Standard, one year on Premium for Entra, Exchange, OneDrive and SharePoint) — learn.microsoft.com; and the 30 days of raw advanced hunting data in Defender XDR, extendable with Sentinel or the raw data streaming API — learn.microsoft.com. Those values are the ones in force on the date this post was published and they change over time and with licensing: check them in your own tenant before using them in a meeting. We have not analysed any affected appliance and have no telemetry of our own on this campaign; everything we report about the incident comes from public sources. What we say about how we work — NetBox as the inventory's source of truth, the rule of deleting alerts that oblige nobody to do anything — is ours and carries no number: we do not publish internal metrics nobody can check.