The Dark Army

Category: Software

  • How UK Banking Apps Are Silently Killing Sessions, Hiding Error Codes, and Gaslighting Users: The Interface Engineering Behind ‘Unexpected Errors’

    How UK Banking Apps Are Silently Killing Sessions, Hiding Error Codes, and Gaslighting Users: The Interface Engineering Behind ‘Unexpected Errors’

    There is a specific kind of rage reserved for staring at a white screen that says “We’re experiencing technical difficulties. Please try again later.” You have no idea if your payment went through. You have no idea if your session is alive or dead. You have no idea if the problem is your connection, the bank’s servers, or some silent fraud flag that just locked your account without telling you. That is not an accident. UK banking apps are engineered to behave exactly this way, and I think it is worth pulling apart why.

    Smartphone displaying a banking app error state during failed session — banking app error states explained
    Photo by Tranmautritam on Pexels

    What “something went wrong” actually means technically

    When a Barclays or Lloyds app throws a generic error, what is happening under the bonnet is usually one of several distinct failure states that the application is deliberately collapsing into a single unreadable message. HTTP 5xx errors from the backend, certificate pinning mismatches, OAuth token expiry, failed biometric challenge responses, rate-limit rejections from the authentication API, all of these have different causes, different recovery paths, and different implications for the user. They get flattened into the same beige modal box.

    This is a deliberate engineering decision. The reasoning given internally is always security: exposing specific error codes gives an attacker more signal. If the app tells you “incorrect PIN, 2 attempts remaining”, an attacker probing accounts knows the PIN space to target. Fair point, up to a point. But the same logic gets applied so aggressively that legitimate users get zero actionable information. Banking app error states end up communicating nothing at all, which is genuinely worse from a usability standpoint and arguably no better from a security one, since a determined attacker just fuzzes the API directly and ignores the UI entirely.

    Session management: the silent kill

    Session timeouts are where things get particularly nasty. Most UK banking apps run aggressive idle timeouts, Nationwide and HSBC both drop sessions after roughly 5 minutes of inactivity in-app, though neither documents the exact threshold publicly. The timeout itself is not the problem. The problem is the transition. A well-engineered app tells you clearly that your session expired and puts you back at a login screen with a clear message. What I have seen repeatedly in practice is something different: the app silently kills the session in the background while leaving the UI in an apparently functional state, so the next action you take, submitting a payment, confirming a standing order, fails at the API layer with no context. The error that surfaces is a generic one, because the session state mismatch gets caught somewhere in the middleware and rethrown as a 500-level response that the frontend handles with its default catch-all handler.

    The result is that users assume the bank’s servers are down, retry the payment, and in some cases submit duplicate transactions. I have seen this pattern cause real financial confusion for people, and the banks’ response is almost always to point at their terms of service rather than acknowledge the session handling is broken.

    Terminal showing authentication error codes related to banking app error states and session management
    Photo by Rafael Minguet Delgado on Pexels

    Authentication throttling and the feedback blackout

    Authentication rate limiting is another place where the engineering decisions get questionable. Throttling login attempts is essential, nobody is arguing against it. But the way UK banking apps implement the feedback around throttling is often actively misleading. When Monzo or NatWest throttles your authentication attempts, the common pattern is to introduce artificial delays without telling you a delay is happening. The spinner just spins. Is it your network? Is it the server? Are you being throttled? You genuinely cannot tell. Some apps go further and return an identical-looking error to a genuine failure, so you cannot distinguish “wrong credentials” from “you have been temporarily locked out” from “the auth service is actually down”.

    Compare this to how a well-designed system handles throttling: clear messaging that says something like “too many attempts, please wait 30 seconds”, a visible countdown, and a distinction between soft lockout and full account lockout. This is not exotic engineering. It is just honest UI. The reason it does not happen in most UK banking apps is partly legal caution, the compliance and legal teams are terrified of confirming to a potential fraudster that an account exists and has been locked, and partly because nobody senior enough cares enough to push back on the default of “hide everything”.

    For a broader look at how this pattern of bad feedback design causes real financial and time costs across digital products, a longer read on why ux design failures in everyday apps are costing british users time, money and patience is worth your time, the problems in banking apps are not isolated.

    The ambiguous UI flow problem

    Beyond individual errors, UK banking apps have a systemic problem with ambiguous state across multi-step flows. Payment journeys are the worst offenders. A typical faster payments flow across Santander or TSB involves four to seven screens depending on the transaction type. At each step, the app holds state locally in memory. If anything causes a page reload or app backgrounding mid-flow, a phone call, a low-memory event killing the app process, a brief network drop, the local state is gone. The app often lands you back at the start of the flow with no indication of whether the previous attempt completed at the server side or not.

    This is genuinely dangerous for users. The PSD2 open banking API surface that sits under these flows does have idempotency key support in most modern implementations, but many of the older in-app payment flows were built before that became standard practice and never properly refactored. The banking app UI layer and the API layer are often built by entirely different teams on different release cycles, and the integration between them is where the worst ambiguous states live.

    Why the FCA is not really fixing this

    The FCA’s Consumer Duty, which came into full effect in July 2023, theoretically requires firms to deliver “good outcomes” for consumers and to avoid “foreseeable harm”. Deliberately obscured banking app error states that leave users confused about whether their money moved seem like exactly the kind of thing Consumer Duty should catch. In practice, the FCA’s published guidance on Consumer Duty focuses heavily on pricing, communications, and support access rather than the technical engineering of UI feedback. Nobody is getting fined for a bad error modal.

    The result is that the incentive structure for banks is almost entirely one-directional: minimise information exposure for risk and compliance reasons, and never face meaningful regulatory consequences for the usability degradation that causes. Security teams win every internal argument because they have a clear threat model to point at. UX teams pushing for better error communication have no equivalent forcing function.

    What good looks like, and why banks avoid it

    Starling Bank is probably the closest thing to a counter-example in UK retail banking. Their app gives noticeably more specific error messages, distinguishing between declined transactions, insufficient funds, card not enabled for international use, and service outages, without apparently handing attackers useful signal. This is achievable because the specificity is contextual: once a user is authenticated and in their own account session, the threat model is different from the pre-auth login flow. The information is only relevant to that authenticated user. It is not obvious attack surface.

    The reason most high street banks do not do this is inertia and risk aversion, not technical impossibility. The engineering required to map specific backend failure codes to useful, user-facing messages is not complex. It is a product prioritisation decision, and it keeps losing to other priorities because nobody at board level is tracking “user session confusion rate” as a metric that matters.

    My take: the engineering behind UK banking app error states is a small but revealing window into how financial institutions actually value their users. Treating authentication throttle feedback as a security necessity while ignoring the financial confusion caused by ambiguous payment states is not a coherent position. It is just the path of least resistance, and it costs ordinary people time and money every day. The same engineering literacy that goes into hardening the authentication stack should go into making the failure states legible. Right now, it does not. And as we have written about before in the context of property fraud infrastructure built on ambiguous communications, opacity in digital financial interfaces is rarely neutral, someone always pays for it.

    Frequently Asked Questions

    Why do UK banking apps show vague error messages instead of specific codes?

    Banks collapse specific failure states into generic errors primarily for security reasons, exposing precise error codes could give attackers useful signal about account status or authentication logic. However, this rationale is often applied far too broadly, stripping out information that would only be useful to authenticated users who pose no additional threat.

    What causes a banking app session to die without warning?

    Most UK banking apps run aggressive idle timeouts, typically between 3 and 10 minutes, and some kill the session silently in the background while leaving the UI in a seemingly active state. This means the next action you take hits an expired session at the API layer, which surfaces as a generic error rather than a clear session-expired message.

    Can a banking app accidentally send a payment twice if I retry after an error?

    It is possible, particularly in older in-app payment flows not built on idempotency keys. If the app loses local state mid-flow and you restart the payment, the second attempt may go through even if the first one processed at the server side. Always check your transaction history before retrying a failed payment.

    Does the FCA regulate how banking apps handle error messages?

    The FCA’s Consumer Duty requires banks to deliver good outcomes and avoid foreseeable harm, which could theoretically cover deliberately confusing UI design. In practice, the FCA’s enforcement focus has been on pricing, communications, and complaints handling rather than the technical specifics of in-app error feedback.

    Which UK banking apps have the best error handling?

    Starling Bank is generally considered the strongest in this area among UK retail banks, providing contextual, specific error messages post-authentication that distinguish between different failure types. Most traditional high street banks lag significantly, defaulting to catch-all generic messages across nearly all failure states.

  • The Technical Reality of the UK Online Safety Act’s Proactive Detection Requirements: What Platforms Are Actually Building to Scan Your Messages

    The Technical Reality of the UK Online Safety Act’s Proactive Detection Requirements: What Platforms Are Actually Building to Scan Your Messages

    The Online Safety Act finally got its teeth. Ofcom’s codes of practice are in force, and platforms operating in the UK are now staring down a legal obligation to detect child sexual abuse material (CSAM) and terrorism content. The political framing is simple. The technical reality is anything but. I’ve spent time reading through Ofcom’s published guidance, the responses from cryptographers, and the actual patent filings from a couple of the major players, and what’s emerging is a genuinely uncomfortable collision between surveillance engineering and the mathematics that makes private communication possible.

    Dark hacker at laptop with terminal code related to Online Safety Act message scanning UK technical analysis
    Photo by Sora Shimazaki on Pexels

    What Ofcom is actually asking platforms to do

    The Act doesn’t mandate a specific technology. What it does is require platforms to use “accredited technology” to identify illegal content, including CSAM, where technically feasible. Ofcom’s published illegal content judgements set the benchmark for what counts as compliance. The phrase “where technically feasible” is doing enormous work in that sentence, and everyone knows it. It’s the legislative equivalent of “sort it out somehow”.

    The two dominant technical approaches being evaluated are client-side scanning (CSS) and server-side hash-matching. They sound similar. They’re not. Server-side hash-matching is what platforms like Facebook Messenger (in its non-encrypted mode) have run for years: you check a file’s hash against a database of known illegal hashes maintained by the Internet Watch Foundation (IWF) or the National Center for Missing and Exploited Children. Easy, non-invasive on E2EE, already deployed. The problem is it only catches known, unmodified content. Crop the image by one pixel, the hash changes. Attackers have known this for a decade.

    Client-side scanning: how the tech actually works

    CSS is the bit that’s causing genuine alarm amongst cryptographers. The idea: before a message or image is encrypted on your device, a local classifier runs on it. If it flags a match against a database of illegal content hashes or a neural classifier trained to recognise CSAM, it can either block the send or generate an alert that gets passed server-side alongside enough decrypted metadata to allow a human review. The encryption still happens. But the scanning happened before it did. This is the crux of the Online Safety Act message scanning UK technical debate.

    Apple’s now-abandoned CSAM detection system (which it pulled in 2023 under pressure) used perceptual hashing via a system called NeuralHash. Rather than a cryptographic hash, NeuralHash generates a fingerprint that’s robust to minor image modifications, so slightly cropped or recompressed versions of known illegal images still match. The hashes were compared locally against an encrypted set derived from NCMEC’s database, using a threshold system: only if enough hashes matched did the system escalate. The cryptographic implementation used a technique called private set intersection so that Apple itself couldn’t see which specific hashes triggered a match.

    Why the cryptographic community is furious

    Researchers at MIT, the University of Cambridge, and Johns Hopkins published a detailed takedown of CSS proposals back in 2021, and nothing has fundamentally changed. The core problem is what I’d call the trusted-client paradox. End-to-end encryption’s security model rests on the premise that only the communicating parties hold the keys. CSS breaks that model not by attacking the encryption directly, but by placing an agent inside the trusted endpoint that answers to a third party. Your phone becomes a surveillance node you don’t control.

    There’s also the classifier reliability problem. Neural perceptual hash classifiers trained on CSAM databases have documented false positive rates. The IWF’s own hash list isn’t static; it changes. What happens when a legal image gets added to the blocklist in error? You get wrongly flagged, your account gets reviewed, and you have essentially no recourse because the detection system is opaque by design. That’s not a theoretical risk. Similar hash-matching systems have already caught legal content. And then there’s the mission creep concern: a scanning system built for CSAM is architecturally identical to one built for political speech. The same infrastructure can be repointed.

    Signal and WhatsApp have both been explicit: if compelled to implement CSS, they’d exit the UK market. Signal’s president Meredith Whittaker called it a “fantasy” that scanning could be made safe. Threema has said the same. The platforms that remain silent on this are the ones you should probably be more worried about.

    What the implementation timeline actually looks like

    Ofcom’s milestones have slipped, but not by as much as some hoped. Category 1 and 2B platforms (the big ones, basically) had to complete their illegal content risk assessments by March 2025. Proactive technology requirements for CSAM detection are expected to be formally enforceable through 2026 and into 2027, with the Ofcom technology notice mechanism being the stick. A technology notice can compel a specific platform to use a specific technology. That’s the legal weapon. No platform has received one yet, but the threat is real.

    The platforms most at risk are the smaller, privacy-focused ones that can’t afford to fight a legal battle or build a compliant system from scratch. Large operators like Meta have the engineering resource to implement something, even if what they implement is deliberately ineffective. Smaller operators just fold. I’d argue that’s actually the most likely outcome for most of the UK’s niche encrypted messaging landscape: quiet withdrawal or quiet non-compliance, with enforcement focused on the visible large platforms.

    The encrypted messaging architecture problem

    The fundamental tension is this: you cannot have both mathematically robust E2EE and server-side visibility into message content. These are mutually exclusive properties. The Online Safety Act message scanning UK technical debate isn’t really a policy disagreement, it’s a dispute about whether a mathematical impossibility can be legislated away. It can’t. What you can do is implement something that looks like scanning without breaking E2EE in a catastrophic or obvious way, and CSS is that thing. It’s a political solution dressed up as a cryptographic one.

    Some researchers are proposing alternatives. Homomorphic encryption-based approaches could theoretically allow a server to compute on encrypted data without seeing it, but the computational overhead is currently too heavy for real-time message scanning at scale. Zero-knowledge proof systems are another avenue, where a user could prove to a server that a message doesn’t match a banned hash without revealing the message. These are interesting. They’re also years away from practical deployment.

    The IWF continues to operate its hash-matching services and actively works with platforms on a voluntary basis. Their PhotoDNA integration predates the Act. What changes with the Act is that voluntary becomes compelled, and the scope expands beyond known-hash CSAM into AI-generated content and real-time video, where the technical problem is significantly harder.

    If you’re running a security operation or pentesting communications infrastructure, understanding this landscape matters. The architecture decisions platforms make under legal pressure create new attack surfaces. A mandatory CSS system that can generate decryption-adjacent alerts is a target. A perceptual hash database is a target. And as we’ve covered before when looking at the GOV.UK Notify API stack, the moment you build a system that can generate official-looking alerts or intercept communications at scale, you’ve created something that adversaries will probe. The legal mandate doesn’t make the resulting infrastructure safe. It just makes it mandatory.

    There’s also a parallel worth drawing to other UK surveillance infrastructure. The same legislative logic that built the national ANPR network into a mass-retention system now applies to message content. The technology gets built for a narrow purpose and then the retention and access rules drift over time. That pattern is consistent enough to be a reasonable prediction, and it’s one the civil liberties community has been making loudly since the Act’s second reading. The difference here is that ANPR doesn’t break the physics of road travel. CSS does break the mathematics of encryption. That’s the distinction that matters.

    My read: the UK ends up with a patchwork. Large platforms implement something, probably a combination of server-side hash-matching for known CSAM and some form of restricted CSS for high-risk categories. Privacy-first platforms either leave or go underground. The cryptographic community remains furious and publishes increasingly detailed breakdowns of why the whole thing is security theatre. Ofcom issues a technology notice to one visible non-compliant platform as an example. And the actual bad actors, as they always do, adapt faster than the regulation can track them.

  • Dissecting the GOV.UK Notify Platform: The API Stack Sending Millions of Official UK Alerts and Why Spoofing It Is Dangerously Plausible

    Dissecting the GOV.UK Notify Platform: The API Stack Sending Millions of Official UK Alerts and Why Spoofing It Is Dangerously Plausible

    Every time your GP surgery texts you a prescription reminder, or HMRC drops you an email about your self-assessment deadline, there’s a good chance that message came through GOV.UK Notify. It’s the Cabinet Office’s centralised messaging platform, quietly powering tens of millions of SMS and email alerts a year across NHS trusts, local councils, the DWP, and more. Most people receiving those messages have no idea it exists. That’s exactly what makes it interesting from a security angle.

    I’ve been pulling apart the Notify API documentation and watching how the platform actually behaves in production. What I found is a well-engineered system with some genuinely smart design choices, sitting inside a trust model that attackers can abuse without touching a single line of Notify’s own code.

    Dark server rack infrastructure powering the GOV.UK Notify API platform
    Photo by Christina Morillo on Pexels

    What GOV.UK Notify actually is

    Notify is a Government Digital Service (GDS) product. Any UK public sector organisation can apply for access, and once approved they get API credentials to send templated emails and SMS messages through the platform. The API itself is RESTful, token-authenticated, and documented openly at notifications.service.gov.uk. GDS publishes the backend code on GitHub too, which is useful for anyone who wants to understand what’s running under the bonnet.

    The architecture is fairly conventional. Client services authenticate with a bearer token (a JWT, specifically), POST to the /v2/notifications/email or /v2/notifications/sms endpoints with a template ID and the recipient’s address or mobile number, and Notify handles the actual delivery via third-party providers. Email goes through commercial transactional mail infrastructure; SMS goes through aggregators with UK carrier connections. The platform abstracts all of that away, which is the point.

    The sender ID trust model and why it matters

    Here’s where the GOV.UK Notify API setup gets genuinely interesting. For SMS, Notify lets organisations configure a custom alphanumeric sender ID. This is the name that appears at the top of your text message instead of a phone number. NHS trusts routinely configure these as “NHSRemind”, “YourNHS”, or similar. Councils use variants of their own names. HMRC uses “HMRC”.

    The problem is that alphanumeric sender IDs in the UK are managed by mobile network operators and their aggregator relationships. There is no central registry that makes “HMRC” an exclusive label that only HMRC can use. A bad actor with a bulk SMS aggregator account can send messages with the exact same sender ID. The message will land in the same conversation thread on an iPhone as a legitimate HMRC text, because iOS and Android group by sender name string. That’s not a Notify vulnerability. It’s a telecoms infrastructure problem that Notify’s output happens to make worse by normalising the expectation that these names mean something.

    For email, Notify enforces DKIM signing on outbound messages and requires sending domains to pass SPF and DMARC checks. That part of the stack is actually solid. Messages sent through Notify from a properly configured service will pass authentication checks. But that also means a phishing campaign that mimics a Notify-style email, using a typosquatted domain like “nhs-notifications.co.uk” with its own valid DKIM setup, looks almost identical to a real Notify email in any mail client that doesn’t surface raw headers. Anyone running email tester services on Notify output will see it score well precisely because the authentication infrastructure is properly configured.

    Terminal output showing GOV.UK Notify API JSON response data
    Photo by Bibek ghosh on Pexels

    Template trust and the social engineering surface

    Notify messages are template-driven. Each approved service builds templates inside the Notify dashboard, and those templates get a fixed ID. When the API call goes out, it references the template and injects personalisation fields. The templates themselves have a particular, recognisable house style: short, plain-language, action-oriented. “Your appointment is on 14 May. Reply YES to confirm or call 0300 xxx xxxx.” That format is now so embedded in UK public consciousness that spoofed messages using the same tone and structure bypass a lot of the mental alarm bells people should be ringing.

    The attack vector I’d flag here isn’t breaking into Notify itself. It’s simulating Notify’s output through independent channels. An attacker who understands how Notify messages are formatted, what sender IDs look plausible, and which services their targets are likely subscribed to (NHS, DWP, council tax) can build extraordinarily convincing lures. The social engineering payload is essentially the platform’s own design language, turned against recipients.

    This connects to a broader pattern I’ve written about before. The UK phishing domain infrastructure piece from earlier this year covers how cheap .co.uk registrations and fast-flux hosting let campaigns stand up convincing-looking service sites in under an hour. Combine that with a spoofed Notify-style SMS pointing to a fake “verify your appointment” landing page, and you’ve got a multi-stage attack chain that requires no Notify compromise at all.

    API security: what Notify gets right

    To be fair to GDS, the Notify API isn’t badly designed. JWT authentication with rotating service-specific API keys is sensible. Separate keys for test and production environments reduce the blast radius of a leaked key. The platform maintains delivery receipts and status tracking through callback URLs, which means consuming services can audit what was sent and when. Rate limiting is in place, though the specific thresholds aren’t publicly documented.

    The bigger risk on the API side is credential hygiene on the consuming service’s end. I’ve seen enough UK government and NHS repositories leaking secrets on GitHub to know that Notify API keys in committed config files are not a hypothetical. A leaked production key gives an attacker direct sending capability from a legitimate service identity, complete with that service’s configured sender ID. At that point you’re not spoofing anything; you’re just using the platform exactly as intended, but for someone else’s recipients.

    What consuming services should actually be doing

    Any public sector team integrating with the GOV.UK Notify API should treat the API key like a private signing key: never in version control, always injected through environment variables or a secrets manager, rotated on a schedule and immediately after any suspected exposure. The GDS documentation says this, but documentation doesn’t always survive contact with a rushed deployment.

    Beyond credential management, there’s a case for including message authenticity signals in the templates themselves. Something as simple as a unique reference number that recipients can verify on the originating service’s website creates a second check. It’s not cryptographic, but it raises the cost of a convincing fake.

    On the SMS sender ID front, the options are more limited because the problem lives at the telecoms layer rather than the application layer. Ofcom has consulted on SMS sender ID protection measures before, and the debate around a UK equivalent of a registered sender registry has been slow-moving. Until that changes, organisations using Notify for high-stakes notifications (benefits decisions, medical appointments) should consider whether SMS is the right channel at all for anything requiring a follow-on action from the recipient.

    The bigger picture: trusted infrastructure as an attack surface

    The GOV.UK Notify API is a good product solving a real problem. Centralising government messaging infrastructure reduces duplicated effort, improves deliverability, and makes it easier for small councils and NHS trusts to send professional communications without building their own transactional mail stack. That’s all genuinely useful.

    But trusted infrastructure attracts attackers because trust is exactly what they’re trying to steal. The more consistently Notify-style messages look and feel authoritative, the more valuable the template becomes for anyone trying to manufacture that same authority fraudulently. It’s the same dynamic that makes DVLA’s vehicle data lookup surface attractive: legitimate systems, widely relied upon, create known expectations that adversaries can exploit from the outside without ever touching the system’s own internals.

    My take is that GDS understands this tension, but the platform’s trust model has outpaced the defensive messaging around it. Most people in the UK have no mental model for how GOV.UK Notify works. They just see an official-looking text from “HMRC” and act on it. That gap between platform sophistication and public awareness is where the real risk lives, and no amount of JWT rotation fixes that.

  • Inside the EU Cyber Resilience Act: What UK Software and Hardware Vendors Actually Have to Implement by 2027

    Inside the EU Cyber Resilience Act: What UK Software and Hardware Vendors Actually Have to Implement by 2027

    The EU Cyber Resilience Act (CRA) received its final approval in late 2024 and its technical requirements are now ticking toward full enforcement. UK vendors who sell digital products into Europe have a hard deadline approaching, and the requirements are not light. We are talking mandatory vulnerability disclosure windows measured in hours, software bills of materials that have to be machine-readable, and default security configurations baked into hardware before a single unit ships. UK product teams are quietly, sometimes frantically, working out what this means for them. Because Brexit did not make the problem go away. If anything, it made it more complicated.

    Hacker reviewing Cyber Resilience Act UK obligations 2027 on multiple monitors in a dark server room
    Hacker reviewing Cyber Resilience Act UK obligations 2027 on multiple monitors in a dark server room

    Why the CRA Still Applies to UK Vendors Post-Brexit

    Here is the thing people get wrong. They assume that because the UK is no longer bound by EU law, European regulations are someone else’s problem. That logic falls apart the moment your product is sold to a customer in Frankfurt or Amsterdam. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK companies exporting to Europe are fully in scope. The EU does not care that your company is registered at Companies House and your servers are in Slough.

    The UK government, for its part, has been developing its own Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024. PSTI covers consumer IoT devices and has some overlapping concerns with the CRA, but the two are not equivalent. PSTI is narrower. The CRA is considerably more demanding and covers a far wider category of software and hardware. UK vendors effectively have to satisfy two separate regulatory regimes simultaneously if they trade in both markets, and the stricter of the two sets the practical floor.

    What the Cyber Resilience Act UK Obligations 2027 Actually Require

    Vulnerability Disclosure: The 24-Hour Rule

    The CRA mandates that manufacturers notify ENISA (the EU Agency for Cybersecurity) of actively exploited vulnerabilities within 24 hours of becoming aware of them. A full vulnerability report follows within 72 hours. This is brutal compared to what most UK product teams are used to. Many organisations currently operate on informal disclosure timelines that stretch across weeks. Under the CRA, 24 hours is the window from awareness to notification, not from patch development to public announcement. UK vendors need a documented incident response process that can actually hit that target, which means tooling, clear ownership, and a direct pipeline to ENISA’s reporting mechanisms.

    The UK’s National Cyber Security Centre (NCSC) has its own coordinated vulnerability disclosure guidelines, which you can review at ncsc.gov.uk. The NCSC framework is broadly sensible but does not impose the same hard legal timelines the CRA does. UK teams targeting EU markets need to treat the CRA timeline as the operative one.

    Developer generating an SBOM output as part of Cyber Resilience Act UK obligations 2027 compliance
    Developer generating an SBOM output as part of Cyber Resilience Act UK obligations 2027 compliance

    Software Bill of Materials: The SBOM Mandate

    An SBOM is essentially an ingredient list for your software. Every component, library, dependency, and third-party module, catalogued in a machine-readable format. The CRA requires manufacturers to produce and maintain SBOMs for products with digital elements. The practical pain here is significant. Large codebases with years of accumulated dependencies can have hundreds of components, some of which are abandoned open-source projects that nobody has touched since 2019. Generating an SBOM is one thing. Keeping it accurate as dependencies update, forks happen, and supply chains shift is an ongoing operational commitment.

    The standard formats getting traction are CycloneDX and SPDX. Tooling exists to automate SBOM generation from source trees and container images, but the output is only as good as the engineering hygiene that produced the codebase. Teams relying on undocumented vendored code or tangled monorepos are in for a rough time. The SBOM also feeds directly into vulnerability management: once you have a machine-readable component list, you can cross-reference it against CVE databases and catch exposure before it becomes a breach notification event.

    Secure-by-Default Configuration Requirements

    The CRA requires products to ship in a secure-by-default state. No more factory passwords shared across every unit. No more open ports that the user is expected to close themselves. No more optional security features that are off unless you know where to look in a settings menu buried three layers deep. The default state of the product must be the secure state. This has hardware implications and software implications in equal measure.

    For web-facing software and hosted products, this translates into enforced HTTPS, no default admin credentials, automatic security updates on by default, and clear discoverability of security settings. The days of shipping a product and leaving hardening as an exercise for the customer are over, at least if you want to sell into Europe legally.

    Which Product Categories Are in Scope

    The CRA splits products into default, important, and critical categories, with increasing requirements at each tier. Most commercial software products sold to businesses and consumers fall into the default category, which still carries substantial obligations. Important products, covering things like password managers, VPNs, routers, and industrial control interfaces, face third-party conformity assessments before they can carry the CE mark the CRA requires. Critical products, including hardware security modules and smart meter gateways, face the most rigorous scrutiny.

    UK vendors supplying B2B software platforms to European enterprise customers need to honestly assess which tier their product sits in. Getting that classification wrong is not a neutral error. Treating an important product as a default product and skipping third-party assessment is exactly the kind of shortcut that generates enforcement action.

    The Practical Scramble Happening Inside UK Product Teams Right Now

    Talk to anyone deep inside a UK software vendor’s security or engineering team and you will hear the same themes. SBOM tooling is being evaluated and bolted onto CI/CD pipelines. Legal teams are trying to map the CRA’s requirements against existing contract frameworks. Product managers are realising that their roadmap for the next 18 months has to absorb compliance work that was not originally budgeted. The Cyber Resilience Act UK obligations 2027 deadline sounds distant until you account for the lead time required to retrofit secure-by-default behaviour into legacy products, build SBOM generation into release pipelines, and train incident response teams on the 24-hour notification clock.

    Web-facing businesses and digital agencies are not immune to this either. Organisations building software products or hosting environments for clients face questions about where their liability sits when a component they ship or maintain carries an unpatched CVE. Businesses like dijitul, a Mansfield, Nottinghamshire-based digital agency specialising in web design, hosting, and software delivery, are already fielding questions from clients about how CRA-adjacent obligations affect the platforms and web properties being managed on their behalf. For an agency operating across marketing, business efficiency tools, and bespoke web builds, the practical question is which of the products and services they deliver would qualify as products with digital elements under CRA definitions. The answer, in many cases, is more of them than you might expect. dijitul.uk is a useful reference point for understanding how smaller digital businesses are thinking through their own product and service taxonomy in light of these requirements.

    The companies that will sail through the 2027 deadline are the ones treating this as an engineering problem now, not a compliance checkbox exercise in 2026. That means adopting dependency scanning tools like Dependabot or Grype as permanent fixtures, not one-off audits. It means building vulnerability triage into sprint cycles. It means having a named person who can make the call at 2am when a critical CVE drops and the 24-hour ENISA window starts ticking.

    How to Start Getting Ready

    The sensible starting point is a product inventory: list everything your organisation ships or maintains that has digital elements and could plausibly reach EU markets. Then classify each item against the CRA’s three tiers. From there, gap analysis against the core technical requirements gives you a prioritised work list. Vulnerability disclosure process first, because the 24-hour window is the most operationally disruptive requirement and the hardest to bolt on retroactively.

    For smaller UK product teams, the SBOM mandate is probably the second most urgent thing to tackle. Integrating CycloneDX generation into your build pipeline is a one-time engineering investment that pays ongoing dividends for both CRA compliance and your own internal vulnerability management posture. It is also the kind of thing that digital agencies running software products for clients, focused on marketing and business efficiency as much as raw web design, need to factor into their service documentation and client-facing agreements.

    The Cyber Resilience Act UK obligations 2027 are not going to be watered down. The EU has spent years building the political and regulatory momentum behind this legislation and enforcement is expected to be real. UK vendors who sell into Europe cannot afford to wait and see. The scramble is already happening. The question is whether your team is in it.

    Frequently Asked Questions

    Does the EU Cyber Resilience Act apply to UK companies after Brexit?

    Yes. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK vendors selling software or hardware into EU member states are fully in scope and must meet the same requirements as EU-based manufacturers.

    What is the vulnerability disclosure timeline under the Cyber Resilience Act?

    Manufacturers must notify ENISA of an actively exploited vulnerability within 24 hours of becoming aware of it, followed by a full vulnerability report within 72 hours. This is significantly stricter than most informal disclosure practices currently used by UK product teams.

    What is an SBOM and why does the CRA require one?

    A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, library, and dependency in a software product. The CRA mandates SBOM production and maintenance so that vulnerabilities in third-party components can be rapidly identified and disclosed across the supply chain.

    What does secure-by-default mean under the Cyber Resilience Act?

    Products must ship in a hardened state without shared default passwords, unnecessary open ports, or security features that are disabled out of the box. The burden of configuration is placed on the manufacturer, not the end user, before the product reaches market.

    What is the difference between the UK PSTI Act and the EU Cyber Resilience Act?

    The UK’s Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024, covers consumer IoT devices and has narrower scope than the CRA. UK vendors selling into EU markets must satisfy both regimes, and the CRA’s requirements are considerably more demanding in most areas.

  • Building a Professional Pentest Lab at Home: Proxmox, Cheap Hardware, and Intentionally Broken Networks

    Building a Professional Pentest Lab at Home: Proxmox, Cheap Hardware, and Intentionally Broken Networks

    If you’re serious about offensive security, you need somewhere to break things without consequences. A proper penetration testing home lab setup is that place. Not a cloud VM you’re scared to nuke. Not a single Kali box on your home network praying nothing escapes. A real, isolated, layered environment where you can simulate corporate networks, run exploit chains, and watch traffic fly across the wire without touching anything that matters.

    The good news: you don’t need a rack of enterprise gear to pull this off. A couple of second-hand machines from eBay, some smart virtualisation choices, and the right software stack will take you further than most people think. Here’s how to do it properly.

    Dimly lit home server setup for a penetration testing home lab setup with multiple small PCs and glowing monitors
    Dimly lit home server setup for a penetration testing home lab setup with multiple small PCs and glowing monitors

    Choosing Your Hardware Without Spending a Fortune

    Forget buying new. The sweet spot for a home pentest lab right now is refurbished enterprise workstations from the previous generation. Think Dell OptiPlex 7060 or HP EliteDesk 800 G4. You can pick them up on eBay for £80 to £150 each, and they come with enough RAM and CPU grunt to run 6 to 8 VMs simultaneously without melting. Aim for at least 32GB of RAM per machine if you can. 64GB is better. RAM is the actual bottleneck in virtualised lab work, not CPU.

    For storage, a 500GB NVMe SSD is the floor. VM snapshots eat space fast. A secondary 1TB SATA SSD for storing vulnerable machine images and packet captures is worth every penny. Network-wise, you want at least two physical NICs per host. One for management traffic, one for lab network traffic. USB gigabit adaptors work in a pinch but buy a proper PCIe card if you can spare a slot.

    Why Proxmox Is the Right Hypervisor for This

    Proxmox VE is the backbone of any serious penetration testing home lab setup. It’s free, it’s open-source, it runs on bare metal, and it gives you full KVM virtualisation plus LXC containers from a single web interface. More importantly, it gives you granular control over virtual networks, VLANs, and bridge configurations, which is exactly what you need for isolation.

    Install Proxmox on your primary host. The installation process is straightforward: grab the ISO from the Proxmox website, flash it to a USB drive, boot from it, and follow the prompts. Once it’s up, you manage everything from a browser at port 8006. No GUI required on the host itself. That’s the point.

    Create separate Linux bridges in Proxmox for each network segment. Your management network, your attack network, your victim network, and optionally a DMZ-style segment if you want to simulate more complex infrastructure. Bridges are cheap to create and they keep traffic logically separated at the hypervisor level before any firewall rules even kick in.

    Network Segmentation: The Part Most People Get Wrong

    This is where amateur setups fall apart. Slapping a Kali VM and a Metasploitable VM on the same flat network and calling it a lab isn’t really teaching you anything about real-world pentesting. Real targets sit behind firewalls, VLANs, and multiple network hops. Replicate that.

    The architecture I’d recommend for a starter lab looks like this. Three segments minimum. Segment one is your management VLAN, home to Proxmox’s web interface and nothing else. Segment two is your attacker network, where your Kali or ParrotOS VM lives. Segment three is your victim network, isolated from the internet and only reachable from the attacker segment via a firewall VM. pfSense or OPNsense running as a VM makes a brilliant gateway/firewall between segments. Configure firewall rules so the victim network has zero outbound internet access. You don’t want vulnerable VMs phoning home or worse, something exploitable becoming a pivot point into your actual home network.

    Proxmox web interface displaying virtual machines as part of a penetration testing home lab setup
    Proxmox web interface displaying virtual machines as part of a penetration testing home lab setup

    VLAN tagging via Proxmox’s Linux bridge configuration means you can have multiple logical networks sharing the same physical switch without traffic bleeding between them. A cheap managed switch like the TP-Link TL-SG108E (around £25 from most UK tech retailers) supports 802.1Q VLANs and is more than adequate for a home lab of this scale.

    Traffic Sniffing Setups That Actually Teach You Something

    Watching packets move is one of the best learning tools available. In Proxmox, you can set up a port mirror by adding a second network interface to your Kali VM that sits in promiscuous mode on the victim bridge. Wireshark on Kali then sees everything traversing that segment. No additional hardware required.

    For more serious work, spin up a dedicated Security Onion VM on its own sniffing interface. Security Onion bundles Suricata for IDS alerts, Zeek for network metadata, and a web-based interface for browsing everything. Pointing it at your victim segment turns your lab into something that closely resembles a real SOC environment. You get to attack, detect, and analyse all from the same infrastructure. That feedback loop is invaluable.

    ntopng is another useful addition if you want a visual traffic dashboard. Lightweight, runs as a container or a VM, and gives you flow-level visibility across your segments in real time.

    The Vulnerable VM Stack Worth Running

    The ecosystem of intentionally vulnerable environments is genuinely excellent right now. Here’s what serious researchers actually keep on hand for a solid penetration testing home lab setup.

    Metasploitable 3 is still worth having. It’s aged but it covers a huge range of classic service vulnerabilities and is well-documented for learning Metasploit workflows. VulnHub machines are downloadable OVAs you import directly into Proxmox. The variety is enormous, from web app focused boxes to full Active Directory environments. DVWA (Damn Vulnerable Web Application) runs as a lightweight VM or Docker container and covers the OWASP Top 10 in a controlled way. If web app testing is your focus, it’s indispensable.

    For Active Directory simulation, which is increasingly important given how many real-world pentest engagements involve AD environments, look at GOAD (Game of Active Directory) by Orange Cyberdefense. It provisions a fully configured multi-domain Windows environment using Vagrant and Ansible. Heavy on RAM but worth it. You’ll need at least 64GB across your lab hosts to run it comfortably.

    Hack The Box and TryHackMe are cloud-based alternatives worth mentioning, though they lack the local control that makes a home lab genuinely educational. Running everything locally means you can pause execution mid-exploit, inspect memory, and modify the environment in ways you simply can’t on a hosted platform.

    The Software Stack Serious Researchers Actually Use

    Kali Linux is the obvious attacker OS and it’s still the default for good reason. The toolset is comprehensive and it’s updated regularly. ParrotOS is a lighter alternative if RAM is tight. For specialised work, BlackArch Linux has an enormous repository of tools not packaged in Kali, though the install process is rougher.

    Beyond the OS, the tools you’ll spend most time in are: Nmap for reconnaissance, Burp Suite Community Edition for web app testing (the Pro licence is around £400/year, worth it if you’re doing this professionally), Metasploit Framework, BloodHound for AD enumeration and attack path visualisation, Impacket for Windows protocol exploitation, and CrackMapExec for lateral movement simulation.

    Document everything with Obsidian or CherryTree. Seriously. Building the habit of writing structured notes during lab sessions is what separates people who can write a real pentest report from people who can just run tools.

    Connecting the Lab to Real-World Skills

    A home pentest lab doesn’t exist in isolation from the broader web ecosystem. Understanding how attackers map and exploit web infrastructure is directly relevant to anyone running or managing online systems. Businesses running their own web presence, including those managing custom software and hosted web properties, are among the most frequent real-world pentest targets. Firms like dijitul, a digital agency based in Mansfield, Nottinghamshire specialising in web design, SEO, and managed hosting, sit at exactly the intersection where the lab skills you’re building become commercially valuable. Their clients at dijitul.uk rely on well-hardened web software and business-critical web infrastructure, the same categories of systems you’re learning to probe in a controlled environment. Understanding vulnerabilities in web design platforms, content management software, and marketing infrastructure means you can communicate risk in terms those clients actually understand.

    The UK’s National Cyber Security Centre publishes solid guidance on what constitutes responsible research and testing, and it’s worth reading their official penetration testing guidance to understand the legal and ethical framework you’re operating within. The Computer Misuse Act 1990 is not optional reading, it’s the law you need to know before you point any tool at anything you don’t own.

    Running a serious penetration testing home lab setup is also a genuine differentiator in job applications and certifications. The OSCP (Offensive Security Certified Professional) exam is essentially a 24-hour practical lab challenge. If your home environment mirrors the structure they use, exam day feels a lot less alien. Same logic applies to the eCPPTv3, CEH practical, and the newer PNPT from TCM Security.

    Beyond certs, the discipline of building and maintaining a proper lab, managing snapshots, documenting findings, tuning firewall rules, correlating IDS alerts, builds the mental model of IT infrastructure that makes you genuinely useful in a real engagement. Tools are just tools. The thinking behind them is what agencies and clients pay for.

    It’s also worth noting that the skills overlap in interesting directions. Penetration testers who understand the business context of the systems they assess, including how web design, software deployment, and marketing platforms are architected, consistently produce more actionable reports. A firm like dijitul illustrates the point neatly: their stack spans hosting infrastructure, custom web software, and business efficiency tooling for clients, each component a potential attack surface that a well-prepared tester needs to understand from the inside out.

    Build the lab. Break things deliberately. Learn what actually happens under the bonnet when an exploit lands. There’s no substitute for it.

    Frequently Asked Questions

    What hardware do I need for a penetration testing home lab setup?

    A second-hand enterprise workstation with at least 32GB of RAM is a solid starting point. Machines like the Dell OptiPlex 7060 can be found on eBay for under £150 and are powerful enough to run multiple virtual machines simultaneously for realistic lab scenarios.

    Is it legal to run a pentest lab at home in the UK?

    Yes, as long as you are only testing systems you own or have explicit written permission to test. The Computer Misuse Act 1990 makes unauthorised access to computer systems a criminal offence, so your lab must be fully isolated from external networks and third-party systems.

    Why use Proxmox instead of VirtualBox or VMware for a home lab?

    Proxmox offers bare-metal KVM virtualisation with full VLAN and bridge support, which is critical for realistic network segmentation. It’s free, stable, and gives you a proper web management interface, making it significantly more powerful than desktop hypervisors like VirtualBox for lab work.

    What vulnerable VMs should I start with as a beginner?

    Metasploitable 3 and DVWA are excellent starting points as they cover a wide range of classic vulnerabilities and are well-documented. Once comfortable, VulnHub machines offer a huge variety of challenges, and GOAD is the go-to choice for practising Active Directory attacks.

    How do I stop my pentest lab VMs from accessing my real home network?

    Use separate Linux bridges in Proxmox for your victim network and configure a pfSense or OPNsense firewall VM as the gateway between segments. Block all outbound internet access from your victim VLAN at the firewall level and ensure your management interface is on a completely separate bridge.

  • Passkeys Are Killing the Password: What You Need to Know in 2026

    Passkeys Are Killing the Password: What You Need to Know in 2026

    Passwords are a disaster. Always have been. We all know it, we’ve all lived it, reused credentials, sticky notes on monitors, “forgot password” links clicked so many times the button should have your fingerprints on it. The security community has been screaming about this for two decades. And now, finally, the fix is going mainstream. Passkeys are here, they’re being deployed at scale, and they’re genuinely as good as the hype suggests.

    Hooded hacker examining passkeys authentication system on multiple dark monitors in a server room
    Hooded hacker examining passkeys authentication system on multiple dark monitors in a server room

    This isn’t vaporware. Google, Apple, Microsoft, and a growing list of UK services have already rolled out passkey support. As of 2026, FIDO2-based authentication is being baked into everything from banking apps to government portals. If you haven’t dug into how this works yet, now’s the time. It’s elegant technology, and understanding it makes you appreciate just how broken the old system was.

    What Are Passkeys and How Do They Actually Work?

    At their core, passkeys are a FIDO2/WebAuthn implementation. That mouthful means: they use asymmetric cryptography instead of shared secrets. When you register a passkey with a service, your device generates a public/private key pair. The service stores the public key. Your device keeps the private key locked inside a secure enclave, on a modern iPhone that’s the Secure Element, on Android it’s similar, on a laptop it often lives in the TPM chip.

    When you log in, the server sends a cryptographic challenge. Your device signs it with the private key. The server verifies the signature using the public key it already has. Done. No password ever travels across the network. No shared secret to breach, leak, or phish. The private key never leaves your device, full stop.

    The unlock mechanism, face ID, fingerprint, PIN, is local authentication only. It proves to your device that you’re the one authorising the sign-in. That’s a crucial distinction. Your biometrics don’t go anywhere near the server.

    Why Passkeys Are a Hacker’s Worst Nightmare

    Think about the attack surface that disappears. Password spraying? Useless. Credential stuffing from a leaked database? The credentials don’t exist to leak. Phishing pages that harvest your login details? The cryptographic challenge is bound to the legitimate origin domain, so a fake site can’t intercept anything useful. Real-time man-in-the-middle attacks? Also neutralised by the origin binding.

    I’ve spent time looking at breach data from services like Have I Been Pwned, and the volume of exposed credentials is genuinely staggering. The UK’s National Cyber Security Centre has long recommended unique, strong passwords for every account, which is sound advice nobody actually follows. Passkeys sidestep the human problem entirely. There’s no password to be weak, reused, or socially engineered out of someone.

    The Sync Question: Convenience vs Control

    Close-up of fingerprint sensor being used to authenticate a passkey on a laptop
    Close-up of fingerprint sensor being used to authenticate a passkey on a laptop

    One thing that trips people up is how passkey syncing works, because it varies by platform and that has real security implications.

    Apple syncs passkeys across your devices via iCloud Keychain, end-to-end encrypted. Google does the same with Google Password Manager. This is brilliant for usability but does mean you’re trusting those ecosystems. If your Apple ID or Google account is compromised, an attacker could potentially access your synced passkeys. That’s the trade-off.

    The more security-conscious among us might prefer a hardware security key approach using something like a YubiKey, which keeps a passkey entirely offline and physically in your possession. No sync, no cloud dependency. The downside is obvious: lose the key and you’re locked out unless you’ve planned recovery properly. There’s no one-size-fits-all answer here. It depends on your threat model.

    For most people, synced platform passkeys are a massive upgrade over password+SMS-based two-factor authentication. For higher-risk individuals, journalists, activists, anyone a digital agency or corporate security team might be protecting, hardware-bound passkeys with proper recovery planning are worth the extra friction.

    What’s Actually Being Deployed in the UK Right Now?

    This isn’t just big tech. HSBC rolled out passkey support for its mobile app. Several UK government services are actively piloting FIDO2 authentication through the GOV.UK One Login programme. Major UK retailers including ASOS and John Lewis have either deployed or announced passkey support in their account systems.

    The pace has accelerated sharply. For a long time, passkeys felt like something on a roadmap nobody was rushing to ship. That changed. Browser support is now solid across Chrome, Safari, Firefox, and Edge. Operating system-level support is mature. The infrastructure is there; it’s just a matter of adoption rolling out through the services layer.

    Password managers like 1Password and Bitwarden have also stepped in as cross-platform passkey vaults, which solves the ecosystem lock-in problem to some extent. If you’re the type who won’t surrender your credentials to Apple or Google, third-party passkey storage is a viable path.

    What About Backwards Compatibility and Transition?

    This is where things get messy in practice. Most services are running passkeys alongside passwords during a transition period rather than ripping out the old system entirely. That means the password fallback still exists, and a determined attacker can potentially force a downgrade to password authentication if the service allows it.

    Ideally, once a user has registered a passkey, services should allow them to delete stored passwords and enforce passkey-only login. Not many do this cleanly yet. It’s a product decision as much as a technical one, and it matters. A system is only as strong as its weakest login path.

    Account recovery is the other elephant in the room. If your device is lost and you haven’t set up sync or backup, how do you get back in? Services handle this inconsistently. Some fall back to email. Some use recovery codes. A few just tell you to contact support. None of these alternatives are as secure as the passkey itself, which is an irony worth sitting with.

    Should You Switch Everything to Passkeys Now?

    Honestly? Yes, where the option exists. For high-value accounts especially: email, banking, work systems, anything touching cryptocurrency or sensitive data. The threat reduction is real and immediate.

    Set up passkeys on your most critical accounts first. Make sure you have a recovery path you’ve actually tested, not just one you vaguely think might work. If you’re on iOS, check your iCloud Keychain is properly secured. On Android, audit your Google Account security. If you’re using a hardware key, buy two and register both as fallback.

    The password era isn’t quite over yet. But it’s ending. The architecture replacing it is genuinely better, and for once the security community isn’t just pointing at the problem. Passkeys are the answer we’ve been waiting for, and in 2026 there’s very little reason to wait any longer.

    Frequently Asked Questions

    What is a passkey and how is it different from a password?

    A passkey is a cryptographic credential stored on your device that uses public/private key pairs instead of a shared secret like a password. Nothing is transmitted to the server during login except a signed cryptographic challenge, so there’s no password to steal or phish.

    Are passkeys safe if your phone gets stolen?

    Yes, because the passkey is protected by your device’s local authentication, whether that’s a fingerprint, face scan, or PIN. An attacker would need both the physical device and the ability to bypass its lock screen to use it.

    Can passkeys be used across different devices?

    Yes. Platform passkeys sync via iCloud Keychain on Apple devices or Google Password Manager on Android, both of which are end-to-end encrypted. Third-party managers like 1Password and Bitwarden also offer cross-platform passkey storage.

    Which UK services support passkeys in 2026?

    HSBC, several GOV.UK One Login services, ASOS, and John Lewis are among UK services that have deployed or are actively trialling passkey support. Major browsers and operating systems all support the underlying WebAuthn standard natively.

    What happens if I lose my device and I've set up a passkey?

    If you’ve enabled cloud sync, your passkeys transfer to a new device when you sign into your Apple ID or Google Account. If you used a hardware key without sync, you’ll need to have registered a backup device or recovery code in advance, so always plan this before you need it.

  • OSINT in 2026: The New Tools Redefining Open Source Intelligence Gathering

    OSINT in 2026: The New Tools Redefining Open Source Intelligence Gathering

    Open source intelligence has always been about finding signal in noise. But the landscape in 2026 looks nothing like it did five years ago. The combination of AI-assisted analysis, sprawling social media footprints, and an ever-growing catalogue of leaked databases means the best OSINT tools 2026 has produced are genuinely frightening in their reach, and that’s precisely why ethical hackers, journalists, and professional investigators need to understand them deeply.

    This isn’t a beginner’s “Google your name” walkthrough. This is what serious reconnaissance looks like right now.

    Anonymous hacker using OSINT tools 2026 on multiple monitors in a dark room
    Anonymous hacker using OSINT tools 2026 on multiple monitors in a dark room

    What Makes OSINT Different in 2026

    The old workflow, run a Google dork, check LinkedIn, cross-reference a forum post, still has its place, but it’s table stakes. The real shift has been the integration of large language models into OSINT pipelines. Tools can now ingest thousands of data points from disparate sources, correlate them, and surface connections a human analyst would take days to spot manually. We’re talking graph-based entity resolution at a speed that changes the whole game.

    At the same time, the attack surface for investigators has exploded. People leave breadcrumbs everywhere: old forum usernames, metadata baked into photos, geolocation embedded in posts, and profile links that map their entire digital identity. That last point is worth dwelling on. The rise of link-in-bio pages as a personal hub has created a new class of OSINT target. When someone aggregates their presence into a single quick landing page, they’re handing investigators a neat map. Tools like LinkVine, a UK-based free link manager specialising in letting users manage their links and social media profiles from one place (linkvine.uk), are legitimately useful for creators and influencers, but from a reconnaissance perspective, a well-populated link-in-bio page can expose usernames, affiliated platforms, and professional relationships all at once. Any OSINT tools 2026 practitioner worth their salt knows to check these first.

    The Core Frameworks Dominating 2026

    Maltego CE and the Graph Approach

    Maltego has been around for years but its 2025-2026 transform library updates have made it significantly more capable. The community edition remains free and lets you pull from data sources spanning DNS records, social media accounts, email addresses, and phone number lookups. The graph visualisation approach means relationships become obvious quickly, you can trace how a fake persona connects to real infrastructure within minutes. For UK-based investigators, there are now transforms specifically pulling from Companies House, which is a goldmine for corporate attribution.

    Spiderfoot and Automated Aggregation

    Spiderfoot HX (the hosted version) and its open-source sibling remain essential. Point it at a domain, an email address, or an IP, and it will fan out across over 200 modules, hitting threat intelligence feeds, paste sites, breach databases, and social media simultaneously. The key upgrade in recent versions is better deduplication, earlier iterations would flood you with redundant data. Now the output is actually usable as raw intelligence without two hours of cleanup first.

    Sherlock and Username Enumeration

    Still one of the cleanest tools in the kit. Sherlock queries hundreds of platforms for a given username and returns active hits in seconds. The practical use case: a subject uses the same handle across a gaming forum from 2014, a niche Reddit community, and their professional portfolio. Sherlock finds all three. From there, you’re building a timeline of their online life. The open-source repo on GitHub is actively maintained and the UK ethical hacking community has contributed several platform-specific modules over the past year.

    Close-up of hacker typing using OSINT tools 2026 reconnaissance frameworks
    Close-up of hacker typing using OSINT tools 2026 reconnaissance frameworks

    AI-Assisted Reconnaissance: Where It Gets Interesting

    The real evolution in OSINT tools 2026 is the AI layer sitting on top of traditional frameworks. Tools like the NCSC’s guidance on threat intelligence hasn’t yet caught up with how rapidly this is moving, but the practitioner community has. Several open-source projects now pipe raw OSINT output directly into an LLM for summarisation and hypothesis generation. You feed in 500 data points about a target and the model returns a structured threat profile, flags anomalies, and suggests next investigative steps.

    There are obvious risks here. Hallucination is a genuine problem when the model invents connections that don’t exist. Every AI-generated summary needs manual verification. The workflow is augmentation, not replacement. Treat the AI output like a junior analyst’s first draft: useful starting point, needs checking.

    Social Media Aggregation: Reading the Clearweb

    Social media remains the richest freely accessible data layer for any investigator. The challenge isn’t finding data, it’s processing volume at scale. Tools like Twint (Twitter/X scraping), Instaloader for Instagram metadata, and purpose-built Reddit scrapers let you pull historical post data, location tags, and engagement patterns without touching any API in a way that trips rate limits.

    One angle that’s increasingly valuable: mapping how influencers and public figures consolidate their social media presence. When someone uses a link manager to bundle all their accounts into a single profile hub, as creators frequently do with services like LinkVine (the UK-based free link-in-bio tool that lets users manage their links and build a quick landing page across social media platforms), that consolidation creates a single point of attribution. Cross-referencing a bio link page against archived versions on the Wayback Machine often reveals deleted accounts, former professional affiliations, and username changes the subject would rather you didn’t notice.

    Leaked Databases and Breach Intelligence

    This is the area that makes legal teams nervous, and rightly so. Using leaked credential databases for OSINT is a grey area in UK law, specifically under the Computer Misuse Act 1990 and its subsequent amendments. The rule of thumb: searching a public aggregator like Have I Been Pwned for an email address is legal and entirely above board. Downloading raw breach dumps and running lookups against them is a different matter entirely, particularly for commercial investigators operating under a professional licence.

    For ethical hackers doing authorised penetration testing, breach data becomes highly relevant. Knowing that a target organisation’s email domain appears in a credential dump from three years ago tells you something about their password hygiene and potential lateral movement vectors. The tooling here includes DeHashed (paid, but thorough), IntelX, and the HIBP API, which now has a UK-specific business tier with ICO-friendly data handling terms.

    Operational Security for the Investigator

    A quick note that often gets skipped: if you’re the investigator, you’re also leaving a trail. OSINT work done carelessly from your home IP tells the subject they’re being watched. Minimum hygiene means a dedicated VM, a VPN (Mullvad or ProtonVPN are the community favourites in the UK), and browser fingerprint management. Whonix over Tor for anything sensitive. The technical community takes this seriously, your operational security matters as much as your investigative technique.

    Building a Repeatable OSINT Workflow

    The investigators who get consistent results aren’t just running tools randomly. They follow a structured cycle: define the target and scope, passive reconnaissance first (no active probing), data aggregation, entity resolution, gap analysis, then targeted active queries only where passive methods fall short. Document everything with timestamps. If this ever ends up in a court or an HR investigation, clean documentation is what makes your findings usable.

    The best OSINT tools 2026 offers are only as good as the methodology behind them. A scattergun approach generates noise. A disciplined framework generates intelligence.

    The gap between what’s technically possible and what most organisations understand about their own public exposure is genuinely alarming. Whether you’re a professional investigator, a red team operator, or someone who just wants to understand the digital footprint they’re leaving behind, 2026 is a year where the tools have leapt ahead of the awareness. Worth getting familiar with both sides of that equation.

    Frequently Asked Questions

    What are the best free OSINT tools available in 2026?

    Maltego Community Edition, Spiderfoot (open-source), and Sherlock are among the most widely used free OSINT tools in 2026. Each covers different investigation types: graph-based entity mapping, automated multi-source aggregation, and username enumeration respectively. Most professional investigators combine several tools rather than relying on one.

    Is using OSINT techniques legal in the UK?

    Using publicly available information for research or authorised investigations is generally legal in the UK. However, accessing private systems or downloading raw breach databases without authorisation can breach the Computer Misuse Act 1990. If you’re working commercially as an investigator, ensure your practices align with ICO data handling requirements and any relevant professional licences.

    How do AI tools improve OSINT investigations?

    AI models can process and correlate large volumes of raw OSINT data far faster than a human analyst working manually. They’re particularly useful for entity resolution, summarising open-source findings, and flagging unexpected connections. That said, AI output must always be verified, hallucinated connections are a real risk that can mislead an investigation if not caught.

    What is the difference between OSINT and active reconnaissance?

    OSINT (Open Source Intelligence) involves gathering information from publicly available sources without directly probing or interacting with target systems. Active reconnaissance involves sending packets, queries, or requests to a target, which can trigger alerts and may require explicit authorisation. Ethical hackers typically complete passive OSINT before moving to any active phase.

    How can organisations protect themselves from OSINT exposure?

    Organisations should regularly audit their own public digital footprint using the same tools investigators use. This means checking what employee details appear in breach databases, reviewing publicly indexed documents for metadata, monitoring social media for data leakage, and ensuring domain WHOIS records don’t expose sensitive contact details. The NCSC publishes practical guidance on reducing organisational attack surfaces.

  • VPN, Tor and Proxy Chaining: How Privacy Nerds Actually Stay Anonymous Online

    VPN, Tor and Proxy Chaining: How Privacy Nerds Actually Stay Anonymous Online

    If you’ve spent any time in privacy circles, you’ll have seen someone claim they’re “100% anonymous” because they’ve got a VPN running. That’s adorable. Real privacy-conscious users know that serious anonymity comes from layering tools – and that VPN Tor proxy chaining done correctly is a completely different beast from just hitting a kill switch and calling it a day. This guide breaks down the actual setups people use, where they go wrong, and what genuinely matters.

    Anonymous hacker setting up VPN Tor proxy chaining on multiple monitors in a dark room

    VPN over Tor vs Tor over VPN – What’s the Actual Difference?

    These two configurations sound similar but behave very differently, and mixing them up is one of the most common beginner mistakes in the privacy space.

    Tor over VPN (VPN first, then Tor)

    Your traffic hits your VPN server first, then enters the Tor network. Your ISP sees you connecting to a VPN – not to Tor – which is useful in countries or on networks that block Tor directly. The VPN provider knows your real IP, but they can’t see your Tor traffic. The exit node sees your Tor traffic, but not your real IP. This is probably the more commonly used setup because it’s simple: connect VPN, open Tor Browser, done.

    VPN over Tor (Tor first, then VPN)

    Your traffic enters Tor first, exits via a Tor exit node, then hits a VPN server before reaching the destination. This is harder to configure and far less common. One real advantage: your destination website sees the VPN IP, not a known Tor exit node IP – useful if a site blocks Tor exits. The downside is that your VPN provider now sees your traffic coming from Tor, which can flag your account and requires a provider who genuinely doesn’t log.

    Adding Proxies to the Chain

    Chaining a SOCKS5 proxy on top of VPN over Tor adds another hop, which sounds impressive but introduces its own headaches. Most proxies don’t encrypt traffic, so if the proxy is the outermost layer, you’re exposing your payload. Where proxies genuinely help is application-level isolation – routing specific app traffic through a proxy while other traffic takes a different path. Tools like Proxychains on Linux let you stack multiple SOCKS5 proxies sequentially, but each additional hop adds latency and a new potential point of failure or logging.

    The important thing to understand with VPN Tor proxy chaining is that more hops doesn’t automatically mean more security. Each node in the chain is a potential leak or logging point. You want deliberate layering, not paranoid stacking.

    DNS Leaks: The Silent Killer of Anonymity

    You can have the most elaborate chain in existence and completely blow it with a DNS leak. When your device sends DNS queries outside your encrypted tunnel – usually defaulting to your ISP’s resolver – your browsing habits are exposed regardless of what’s happening at the IP layer. This happens constantly with poorly configured VPN clients, split tunnelling gone wrong, or operating systems that use their own DNS resolution in parallel.

    Testing for leaks is non-negotiable. Run a DNS leak test before you trust any setup. On Linux, hardcoding DNS to a resolver that routes through your tunnel and disabling systemd-resolved’s fallback behaviour are basic hygiene steps. On Windows, it’s messier – the OS loves to query multiple resolvers simultaneously. WebRTC leaks are equally dangerous in browsers: your real IP can be exposed through browser APIs even when your network traffic is tunnelled. Disabling WebRTC in Firefox via about:config or using a properly hardened browser profile is essential.

    Browser Fingerprinting: Why Your IP Is the Least Interesting Thing About You

    Here’s where a lot of technically-minded people still drop the ball. Even with a flawless VPN Tor proxy chaining setup, if your browser is leaking your screen resolution, installed fonts, canvas fingerprint, timezone, and hardware specs, you’re uniquely identifiable. Sites like Coveryourtracks (run by the EFF) will show you exactly how unique your browser fingerprint is – most people are shocked.

    Tor Browser handles this by standardising fingerprint values across all users – that’s the whole point of its hardened defaults. The moment you install extensions, change window size, or enable JavaScript on sketchy sites, you start differentiating yourself from the crowd. Brave with fingerprint randomisation enabled is a reasonable middle ground for day-to-day use, but it’s not Tor-level anonymity. If anonymity actually matters for what you’re doing, use Tor Browser and don’t touch the defaults.

    Where People Actually Mess Up Their OPSEC

    Technical setups fail less often than the humans running them. Here are the real-world slip-ups that unravel otherwise solid configurations:

    • Logging into personal accounts while chained. The moment you sign into Gmail or any account tied to your identity, the game is over. Anonymity is about behaviour, not just routing.
    • Inconsistent usage patterns. If you only activate your privacy setup when doing specific things, you’ve created a timing correlation between your “anonymous” activity and your real behaviour. Consistency matters.
    • Trusting free proxies. Free SOCKS5 proxies are almost universally either logged, compromised, or run as honeypots. Pay for infrastructure you can verify, or self-host.
    • Forgetting about metadata. Files you download and re-upload can contain EXIF data. Documents carry authorship metadata. Strip it before sharing anything.
    • Assuming Tor is magic. Tor anonymises your network layer. It does not protect you from malware, bad exit nodes serving modified content, or correlation attacks by well-resourced adversaries.

    What Setup Actually Makes Sense?

    For most people who genuinely care about privacy rather than performing it, the practical answer is: a reputable no-log VPN combined with Tor Browser for anything sensitive, DNS leak testing as a habit, and strict separation between anonymous and personal activity. Full VPN Tor proxy chaining with multiple proxy hops is worth learning and understanding, but for the majority of threat models, it’s overkill that introduces more failure points than it eliminates. Know your threat model first – then build a setup that actually fits it, rather than the most impressive-sounding one.

    The nerds who are genuinely hard to track aren’t running the most complicated setups. They’re running disciplined ones.

    Terminal screen displaying VPN Tor proxy chaining network configuration commands
    Privacy-focused users discussing VPN Tor proxy chaining setup in a dark urban setting

    VPN Tor proxy chaining FAQs

    Is chaining a VPN with Tor actually more secure than using either alone?

    It depends on your threat model. Combining a VPN with Tor can hide Tor usage from your ISP and protect your real IP from Tor exit nodes, but it also introduces your VPN provider as a potential logging point. Done correctly with a verified no-log provider, it adds meaningful protection – but it’s not automatically better if you misconfigure it or choose an untrustworthy VPN.

    How do I check if my VPN setup has a DNS leak?

    Use a site like dnsleaktest.com or ipleak.net while your VPN is active and run the extended test. If you see your ISP’s DNS resolver or any server outside your VPN tunnel appearing in results, you have a leak. On Linux, you can lock DNS resolution to your tunnel interface using resolv.conf or by configuring systemd-resolved to route all queries through the VPN.

    What is browser fingerprinting and does a VPN protect against it?

    Browser fingerprinting is the process of identifying you based on your browser and device characteristics – screen resolution, fonts, canvas rendering, timezone, and more – rather than your IP address. A VPN does not protect against fingerprinting at all. You need a browser like Tor Browser that standardises these values, or at minimum, browser-level protections like Brave’s fingerprint randomisation.

    Can free proxy servers be trusted for anonymity?

    Broadly, no. Free proxy servers are frequently run without any logging policy, and many are operated specifically to harvest traffic data or serve as honeypots. If a proxy is free, someone is paying for it another way – usually with your data. For any serious use case, either pay for a verified service or self-host a proxy on a VPS you control.

    What is a WebRTC leak and how do I stop it?

    WebRTC is a browser API used for real-time communication like video calls. It can expose your real IP address directly through the browser, bypassing any VPN or proxy setup entirely. To block it in Firefox, go to about:config and set media.peerconnection.enabled to false. In Chromium-based browsers, use a dedicated extension like WebRTC Leak Prevent, or switch to Tor Browser which blocks it by default.

  • Email Security For Hackers: Beating Modern Phishing Traps

    Email Security For Hackers: Beating Modern Phishing Traps

    If you live online, email security for hackers is not optional. Your inbox is the soft underbelly of your entire identity: password resets, crypto exchanges, cloud access, everything. You can run hardened Linux, tunnel everything through Tor, and still get wrecked by one lazy click in Gmail.

    Anonymous hacker in a dark room reviewing inbox to improve email security for hackers

    Why email security for hackers actually matters

    Most serious breaches still start with phishing. Not zero days, not Hollywood-style remote exploits – just weaponised psychology plus a half decent HTML email. Once an attacker owns your inbox, they can reset accounts, impersonate you, and pivot into any system that trusts your email address.

    For hackers and techies, the risk is bigger. You are a higher value target: you probably have access to repos, admin panels, VPNs, maybe even company infra. One compromised mailbox can become a full-blown supply chain incident.

    How modern phishing bypasses basic defences

    Old school phishing was easy to spot: bad spelling, weird domains, pixelated logos. Modern campaigns are cleaner, faster and often partially automated. A few tricks that keep catching people out:

    • Pixel-perfect clones of login pages hosted on lookalike domains, sometimes with valid TLS certificates.
    • Thread hijacking, where an attacker who already owns one account replies inside a real conversation with a malicious link or attachment.
    • OAuth consent scams that never ask for your password at all, just trick you into granting a rogue app access to your mailbox.
    • Multi-factor fatigue, spamming push notifications until you hit approve just to make them stop.

    Spam filters catch a lot, but not all. The nastiest campaigns are low volume and targeted, which means they often look like normal mail to automated systems.

    Core principles of email security for hackers

    Forget silver bullets. Think layers. Stack enough friction between an attacker and your inbox and they will usually move on to an easier target.

    • Segmentation: never use the same mailbox for personal logins, work access, experiments and burner stuff. Compartmentalise identities.
    • Hardware backed MFA: use security keys (FIDO2 / WebAuthn) wherever possible. SMS codes are better than nothing, but still weak.
    • Unique, long passwords: password managers exist for a reason. If your email password leaks, it should not unlock anything else.
    • Minimal exposure: do not splash your primary address across random sign ups. Use aliases or catch-alls for junk.

    Hardening your mailbox like an attacker would

    Think like you are trying to break into your own account. Where are the weak points?

    • Account recovery paths: audit backup emails and phone numbers. Remove anything you do not fully control.
    • Third party app access: review connected apps and revoke anything you do not recognise or no longer use.
    • Forwarding rules: silent auto forwards are a classic persistence trick. Check and clear them regularly.
    • Filters and labels: attackers sometimes hide their own messages by auto labelling and archiving them.

    When you are testing deliverability or playing with custom domains, it is worth running your messages through a tool like mail tester to see how your headers, DNS records and content look from the outside. The same intel that helps you build legit systems also helps you spot malicious ones.

    Spotting phishing like a pro

    Technical controls help, but your brain is still the main IDS. A few quick checks before you click anything sensitive:

    • Hover links and check the full domain, not just the brand name at the start.
    • Pop the email into raw source view and inspect the headers if something feels off.
    • Be paranoid about “urgent” security alerts that demand immediate action.
    • Never log in from a link in an email if you can avoid it – open a new tab and type the domain manually.

    Building a paranoid workflow that still feels usable

    Email security for hackers does not have to be painful. A few habit tweaks go a long way:

    Laptop secured with a hardware key representing strong email security for hackers
    Cybersecurity analyst inspecting raw headers to strengthen email security for hackers

    Email security for hackers FAQs

    Why is email security for hackers more critical than for regular users?

    Hackers and technical users usually have access to higher value targets such as source code, admin panels, infrastructure dashboards and crypto accounts. If an attacker compromises your inbox, they can reset passwords, impersonate you and pivot into systems that trust your email address. That makes email security for hackers a priority, not a nice to have.

    What is the single biggest improvement I can make to my email security?

    If you do nothing else, enable hardware backed multi factor authentication on your primary mailbox and lock down your recovery options. That one change makes password theft, basic phishing and credential stuffing far less effective, and dramatically raises the effort required to take over your account.

    Should I use different email addresses for different online identities?

    Yes. Segmentation is a core part of email security for hackers. Use separate mailboxes or at least aliases for personal life, work, experiments and throwaway sign ups. That way a compromise in one area is less likely to spill over into everything else you do online.

The Latest