A Complete Security Assessment of One Windows 11 Laptop ​

August 26, 2026 · InfraScout Team

At the end of this assessment you have a prioritized list of findings by severity, a pass/fail table against a recognized baseline, a stored baseline for the host, and a written report that shows the evidence for every control, including the ones that passed. You get all of it from one chat, and nothing on the laptop changes.

The scenario here is a Windows 11 laptop from a shared mobile pool, but the pattern works for any single Windows client.

The problem ​

A laptop is easy to check superficially and hard to check thoroughly. A real assessment covers credential protection, audit coverage, relay exposure, persistence, per-user software, and how the device looks from your cloud tools. That is hours of PowerShell and write-up. With InfraScout, the AI does the collection, verification, and documentation through the device's agent, and you spend your time steering and challenging it.

Starting the assessment ​

A short prompt is enough to start:

text
Run a full security assessment of this Windows 11 laptop. It's a shared
pool device. Stay read-only, verify anything alarming before you record it,
save findings as insights, and give me a prioritized fix list at the end.

The AI first resolves the host and confirms that its agent is online with PowerShell, event log, WMI, and performance capabilities. It pulls the host summary, the device's group memberships, and any baseline stored from earlier work. If earlier work exists, it consolidates instead of repeating. Then it lays out a visible plan (patching, accounts, antivirus and firewall, encryption, network exposure, persistence, logging) before it starts.

Verify before recording ​

The first pass is read-only PowerShell across the plan. The most useful thing the AI does here is decline to take alarming signals at face value.

Microsoft Defender reports as off. Before recording that, the AI checks Windows Security Center and finds a third-party antivirus registered as the primary provider, which puts Defender into passive mode by design. RDP is listening even though the local registry says it is disabled. Instead of calling that a misconfiguration, the AI checks the applied policy and finds a policy setting that overrides the local value. Both lead to more accurate findings than the raw signal would have.

The AI also corrects itself. Early on it reports that there are no failed logons, which sounds reassuring. When it later checks the audit policy, it finds that failed logons are not audited at all. It withdraws the earlier statement and saves the missing audit coverage as a finding.

TIP

Ask the AI to say how it knows something, not just what it found. "No failed logons" and "failed logons are not recorded" read the same in a summary and mean opposite things.

Go deeper, then ask what was missed ​

After the first pass, a short instruction such as "go deeper" moves the work into a new session covering credential protection, persistence mechanisms, the certificate store, PowerShell logging, local administrator password management, and similar controls.

Then you ask the question that improves any assessment: what did you miss? The AI compares its work against the CIS Benchmark and the Microsoft security baseline for Windows 11, lists the gaps, and asks which ones to cover. If you answer "all of them, and save the checklist," it stores the resulting checklist as a reusable pattern, so the next client assessment starts from the full list.

Application review follows the same approach. The AI builds a full software inventory and compares versions against known-exploited vulnerabilities. It also points out that its first query covered only machine-wide installs and reruns the check for per-user installs, which is where software outside central management usually sits.

Correlating with the cloud ​

A client assessment is incomplete until you know what your central tools see. The AI queries Microsoft Intune and Microsoft Defender for the device. In this scenario the device appears in neither, so the AI records a visibility gap and notes that the device might be managed from a different tenant. In a later pass, it runs this correlation as a parallel task alongside the host deep-dive, which shortens the round.

You can challenge the framing here too. If you ask whether "not onboarded to cloud EDR" is really a finding when another endpoint protection product runs, the AI reframes the finding around the question that matters: does anyone receive central detections and alerts from this device? When you ask what it still hasn't checked, it names two remaining gaps, Office macro and mark-of-the-web policy and end-of-life runtimes in its own inventory, and closes them.

One root cause behind many symptoms ​

Individually, the findings look scattered. The applied-policy listing explains many of them: the device has no dedicated security baseline policy. Missing audit categories, an unconfigured attack surface, and permissive defaults all follow from that one gap, so you fix it by assigning a baseline rather than working through a dozen separate tickets.

In this scenario, the findings include:

  • A widely exploited vulnerability in an archive utility outside central patching, rated critical
  • No security baseline policy, missing audit categories for failed logons and process creation, and no PowerShell script block logging
  • No central detection and alerting visibility, and the device missing from cloud management
  • Credential Guard off even though virtualization-based security runs with memory integrity only
  • Disk encryption without a pre-boot PIN on a shared device
  • Relay exposure from LLMNR, NetBIOS, and unenforced SMB client signing
  • Unconfigured application control, exploit protection, and USB/DMA restrictions, plus SmartScreen disabled

Smaller findings cover contradictory update policy settings, end-of-life .NET runtimes, third-party apps a few versions behind, two data sources that disagree about SMB1, and an orphaned scheduled task pointing at a share that no longer exists. When two sources disagree, the AI records the disagreement itself as a finding instead of choosing one.

The passed controls count as much as the failures: full-disk encryption, Secure Boot, TPM, LSA protection, memory integrity, a locally managed administrator password, the firewall on all profiles, no local administrator sprawl, and a clean certificate store.

What the assessment covers ​

The reusable checklist that comes out of this session covers these areas:

  • Patch level, including cumulative update failures and error codes in update history, not just the build number
  • Antivirus, EDR onboarding, and central alerting
  • Disk encryption, Secure Boot, TPM, and pre-boot authentication
  • Credential protection: LSA protection, Credential Guard, and local administrator password management
  • Audit policy, PowerShell logging, and event log coverage
  • Network exposure: listening services, firewall profiles, and name-resolution and SMB relay risks
  • Attack surface: application control, exploit protection, SmartScreen, Office macros, and device restrictions
  • Persistence, scheduled tasks, and the certificate store
  • Software inventory, including per-user installs, against known-exploited vulnerabilities and vendor lifecycles

The deliverables ​

The session ends with under twenty insights across critical, high, medium, and low severity, each linked to the evidence behind it. The AI stores a per-host baseline in memory for future comparisons and produces a pass/fail table against the checklist.

A severity chart alone doesn't tell you what to fix, so ask for the findings written out too. The written report covers evidence, risk, and recommendations for each finding, and documents passed controls with their evidence, which makes it defensible when someone asks how you know a control is in place.

In this scenario the whole assessment took a couple of hours, spread across several sessions as the questions deepened.

Staying read-only ​

The assessment runs in read-only mode, and the AI states at the start that it changes nothing without your confirmation. When the read-only PowerShell mode blocks a command construct, the AI rewrites the command instead of working around the restriction. Each round is submitted for review, findings that you challenge are reframed in the open, and anything the AI cannot verify is labeled as unverified.

INFO

The same discipline carries into remediation: the AI diagnoses read-only first, presents a graded plan, and asks before each state-changing step, such as a reboot, telling you first if a user is signed in.

Next steps ​

To run this pattern on your own clients, start with how findings are stored and reviewed in Insights, then look at the agent capabilities in Agent tools. For the cloud correlation step, see Microsoft Intune. To see how host baselines and saved checklists carry over between conversations, see Memory.