ENISA Launches Single Reporting Platform for EU CRA; UK Gov't Rolls Out Passkeys; New Apple Watch Features Continuously Listen & Transcribe

The biggest challenge for vendors and regulators will be turning these regulatory deadlines into operational reality. A vulnerability, whether discovered internally or reported by someone externally, does not always arrive neatly packaged with all the information needed to determine its severity, impact, and whether it triggers a reporting obligation. With the CRA's 24-hour reporting clock now in force, organisations need to ensure they have the right policies, processes, training, and people in place to quickly assess vulnerabilities and incidents and meet their obligations. At the same time, we need to avoid creating a compliance-driven reporting culture that generates huge volumes of low-value reports simply because organisations are worried about missing a regulatory deadline. The goal of the CRA should be better cybersecurity and more secure products, not simply more cybersecurity paperwork.

The CRA is broad in coverage, meaning it covers anything digital sold in the EU, from baby-monitors to smart watches, applications, connectable hardware and software. The purpose was to raise the bar on digital product security, to include timely security updates, support periods, guidance on modifications, and aid for consumers in setting products up securely as well as measures to make it easier to identify hardware and software with appropriate security features. Compliant products will have the CE marking. With the broad applicability of the CRA, you should read the document to understand how it may apply to you, even if you're just providing open-source software others use. The guidance, which is 84 pages, provides detailed information and examples, but even so, you want to pace yourself. There is a lot to digest here, so you're going to want to read it a couple of times. Start getting processes, reporting, etc. set up now — it'll be December 11, 2027 before you know it.

I have mixed feelings about this one, and I suspect a lot of product security teams do too. On one hand, I'm glad to see regulation pushing manufacturers to treat an exploited vulnerability as something you own publicly and quickly, not something you quietly fix in the next release. Defenders need to know where they should focus. On the other hand, 24 hours goes by fast and it's unclear to me when that 24-hour clock starts. The good news is that the early warning doesn't ask for much — it's essentially “we know, and here's where it's sold” — so nobody should be holding that notice hostage to a full investigation. This isn't just about the products you ship next year. It already applies to what's on the EU market today, legacy products included. So the real question is whether you can tell rapidly which of your products has the vulnerable component in it, whether that vulnerable component is exploitable, and whether it's been exploited. Even if you have an accurate SBOM locked down, you may still have work to do to validate findings. This plays into the larger conversation about vulnerability operations and ongoing processes to separate “vulnerable element is present” from “exploitable condition is confirmed.”

I think this new platform would be another critical data source for judging whether the promised vulnerability apocalypse is actually coming or perhaps already here. If they collect vulnerability data, exploitation data, mitigation, and (hopefully) resulting incident loss from exploitation, we will know for sure.

Again, while recognizing the need for timely reporting, arbitrary time requirements are not helpful.

Bravo UK One Login! If you've not played with passkeys, you need to. Think of phishing resistant MFA without the SMS risks. When an application offers one, accept it, adding it to the appropriate wallet, and then log in with it. Learn what happens when you switch devices or use a password manager for cross-device access. The goal is to be ready to tell your users they can successfully adopt passkeys as well as to build support for implementation/rollout in your shop.

A bold move by the UK as it digitizes the delivery of vital government services. Moving to passkeys is the right approach, and the pilot's success speaks for itself. Now, here’s to rolling out passkeys to the remaining 90 percent of UK citizens.

While there are exceptions and limitations, across most applications and environments passkeys are the most convenient and secure strong authentication mechanism. It should be the default choice. Get on with it.

I wish more entities rolled out passkeys to all their users.

I’m not a lawyer, far from it, but has anyone in the legal area looked at how this is considered when you're in a state that has two-party consent laws for recording? Would these systems fall into that? Having an automatically always-listening audio device in my proximity is something that I would be highly suspicious of. Then again, we already have so many other ambient listening devices; someone is always listening, aren’t they? From a physical security perspective, I’m not exactly sure how we police this in 2026.

Not going to throw Apple under the bus here, as they appear to be taking steps to limit what is captured and how it's stored. But it's a good time to consider — especially in a business environment — that all electronics with microphones, from smart watches and phones to TVs and digital assistants, may be listening, recording and processing full time. Then assess the risks of having them in the presence of sensitive conversations. Be sure to differentiate recordings where you're controlling the distribution and storage from these ad-hoc scenarios. Think of someone with an unreported tape recorder in a meeting. Provide appropriate guidance and policy with some teeth, and don't assume people will do the right thing.

As an organisation that has built a reputation around protecting its customers' privacy, this feels to me like a backward step for Apple. From watches that listen to our conversations, to glasses that record video, to AI systems accumulating and analysing ever more of our personal data, it seems tech companies are stubbornly pushing us towards a society where people will increasingly struggle to protect their right to privacy. With always-on AI-enabled devices becoming more commonplace, we need to consider not simply the privacy of the person who owns the device, but the privacy rights and expectations of everyone around them who may never have consented to being recorded, transcribed, or analysed.

Keep an eye out for upcoming litigation — that feature is packed with heavy safeguard logic. To get ahead of the curve, Apple should demystify how the Secure Enclave operates on the Apple Watch through a targeted series of technical deep-dives or journal posts.

Last month, on the previous GitLab critical, I said I'd started expecting sub-24-hour exploitation to become the norm. Case in point: Within a day of disclosure, this one was in the KEV and probes started hitting honeypots. The public evidence so far is just scanning plus a KEV listing, not a list of named victims, but with an unauthenticated file read on the system that holds your source code, pipeline config, and secrets, we don't need to wait for a victim list to assume there will be victims. Patching closes the door to future attacks, but it doesn't tell you whether someone already walked through it. Pull your access logs and look for the indicators in the POST requests. If you find them — or if your logs don't go back far enough to rule them out — treat the credentials and tokens on that box as burned and rotate them. And my comment from last time still stands: Two exploited criticals in a month in one of your most sensitive applications is exactly why painless, safe upgrades have to be a design priority for vendors, not a nice-to-have.

The update can be applied with zero downtime in a multi-node instance. Focus on getting to version 19.3.2, as there are a lot of other bug fixes you're going to want to leverage there. Make sure that you identify all the self-hosted GitLab instances in your environment, check that they all were updated, and check their access logs on the repository commits API for any unauthorized activity which may indicate probing or exploitation attempts.

Any type of source code tree is going to be widely valuable, but especially so now — so much of our core business is done through automation, including just the ways that we pull in libraries, that any organization hosting their git infrastructure publicly should be very sensitive to exploits. AI Tools and LLMs will absolutely take advantage of these systems, and organizations should not lose sight of that.

Code reuse is essential to the efficiency of computer use. However, code repositories are particularly attractive targets, because if compromised, they can be used to spray malware. They should employ stringent and timely security, even, if necessary, at the cost of user convenience. Users should consider the risk.

By the time a bug lands on the KEV, it's already in the wild. The oldest of these had a public advisory for 6 weeks before it would have tripped the “KEV == Priority to Patch” indicator many orgs have for prioritizing fixes. Attackers can grab a token for the anonymous user even when anonymous access is disabled (which means even if you thought you had things securely configured, you've still got to check for evidence of exploitation and patch). From there it took under five minutes to reach admin. We're going to keep seeing these speed runs, folks. Strap in. If you run Artifactory: Audit admin accounts and tokens, review installed plugins, rotate keys, and check /tmp, /var/tmp, and /dev/shm for staged payloads. Weaponization of build pipeline trust is the hot thing for exploits in 2026.

The flaws can be remotely exploited without authentication. Exploiting an Artifactory zero-day flaw was how the OpenAI models broke out of their cages to attack Hugging Face back in July. Use this, as well as the KEV information, to get the go-ahead on patching right away.

From my experience dealing with cyberattacks, particularly ransomware attacks, remote management software is increasingly being used by criminals to break into and maintain access to organisations. You should maintain a clear inventory of authorised remote management software for your organisation, restrict who and what can access it, and treat critical vulnerabilities affecting those systems as priority incidents rather than routine patching exercises.

That KEV deadline was yesterday. Short version: Update your ScreenConnect server to 26.6.5, then reinstall your host clients and update your access agents, both of which can be done centrally. If you're on the cloud service, you still need to reinstall the host clients and update access agents. The attackers are using social engineering to trick victims into executing rogue ScreenConnect clients, including VBScript files which establish persistence and then check for active sessions to propagate them to other ScreenConnect clients. Don't forget to hunt for the IOCs — they're in the Huntress blog.

While you're patching your officially official RMM tool of YOUR choice, please verify lack of other RMMs of THEIR choice, of which there are many more than most know about... See this project for most of the RMM tools out there: https://lolrmm.io/ An unapproved RMM landing on a box is an incident. Find ways to detect them and respond accordingly.

Here we go, another unauthenticated RCE exploit. This time on your VPN gateway, which was already a target. CVE-2026-85102 impacts Security Gateway and Check Point Spark Firewall using Site to Site VPN or Remote Access VPN; CVE-2026-85103 impacts the Check Point Security Management Server, Security Gateway and Spark Firewall. In addition to applying the update, if you're using a Site to Site VPN, you'll want to disable implied rules for VPN and manually define access for UDP/500 & UDP/4500 to specific peer IP addresses. Make sure that you have Check Point LivePatch enabled to get patches automatically.

Is it time (again) to reconsider VPN and its place in the larger architecture? Did we talk about this before a few times, something about zero trust, and something about some netsec vendors' history of security flaws worse than their supposed cure of (checks notes) tunneling already HTTPS traffic to a centralized and vulnerable choke point (usually on-prem appliances...)? I started using VPNs when HTTPS everywhere was not a thing, but I do wonder why we're still using VPNs in use cases where they hurt more than help... #OldTrollIsTrolling

Cybercrime is ultimately a business, and $12.7 billion demonstrates just how profitable that business has become. Disrupting the infrastructure that enables criminals to move and launder money can be just as important as disrupting the technical infrastructure used to launch attacks. If we can make cybercrime harder to monetise, we make it less attractive to criminals.

The cryptocurrency scams seem to be spread across all age groups. The attackers essentially tricked victims into transferring large sums of money from retirement or other savings plans to buy fictional digital assets or property, and then returned posing as investment recovery services — it was their charging a fee for recovery which caused victims to realize they were being scammed. Treasury is seeking reporting from all financial institutions, banks, credit unions, and non-traditional. If you're using cryptocurrency, make sure that you know what's behind it; things get really dicey when you're working with an organization which has been sanctioned by OFAC.

The price of this insider was a relatively affordable $1,000 to $2,000 per swap, and the person who recruited him into the scheme was a family member. Carter's co-conspirators walked into the store posing as victims, and he did exactly what his job allowed. Every organization has that same kind of attack surface: the help desk that resets MFA, or the admin who changes a recovery address. You must require a second person or an out-of-band callback for those changes, and alert on unusual volume. Note that what limited the damage was bank fraud controls. The financial industry has built incredible intelligence, detections, and algorithms to watch for this behavior because of the extreme losses it can lead to. What are the cell service providers doing to enforce tighter controls on SIM swaps and raise awareness within their own workforce? Other than two-person control (which could still be compromised by an adversary who manages to find 2 insiders willing to work together on the scheme), what can be done to protect this that doesn't overburden the consumer? I know, I know, we just barely got (almost) everyone on SMS-based MFA, but we're going to have to pick up the pace moving to hardware tokens, passkeys, and more robust methods, because SIM-swapping is too easy and too lucrative. Most major carriers offer number-lock or SIM-swap protection features which put an additional layer of protection on your account, so call your cell phone provider to ask about it (and help your friends and family do the same).

The word needs to get out that cyber-crime is not without consequences. Whether an insider, as in the AT&T SIM swapping, or those developing and deploying ransomware, criminals are being found, extradited, and prosecuted. I suspect more legal precedence will need to be developed before the judgements (aka fines) begin to approach appropriate restitution, but even so, celebrate the wins where they happen.

I use some SMS for OTPs because it is convenient. I think that I would recognize a successful attack within hours. However, I rely upon AT&T management of provisioning to assist me in the event of a new phone while resisting SIM swapping attempts. Passkeys would be even safer and more convenient but are still not widely offered. Even when passkeys are offered, one may have to go through gratuitous extra steps so that they are not as transparent as they are intended to be.

SIM swapping isn't easy to pull off, so Carter and his co-conspirators targeted the weakest link in the security chain.