Check Windows hardening offline – without an agent, on plant, lab and control-room PCs

Why agents, installations and network scans often don’t work on plant PCs

HMIs, engineering workstations, lab and control-room PCs often sit outside central IT: some without a network, some validated or accepted by the plant vendor, some running software that needs an insecure setting. Anyone who has to show how well Windows is hardened there runs into hurdles that office IT does not have:

• Every installation is a change

  Installing a checking tool changes the system. For computerised systems in GMP environments, EU GMP Annex 11 states that changes – explicitly including system configurations – should only be made in a controlled manner, following a defined procedure.

• The plant vendor has a say

  NIST’s guide to OT security (SP 800-82) points out that OT vendor licensing and service agreements sometimes rule out third-party security solutions, and that support can be lost if third-party applications are installed without the vendor’s approval.

• Updates need testing and downtime

  According to NIST, updates on OT systems need thorough testing by both the vendor and the end user; outages are planned days or weeks ahead, and revalidation may be needed. An agent that updates itself regularly is a poor fit.

• Active network scans can disrupt

  NIST advises extreme caution: active scans may cause device instability or interfere with the process state and should run during planned outages where possible. Solutions that scan actively or use resources on the machine itself should be tested before they are deployed in the OT system.

• Some machines have no network at all

  An isolated measurement PC or an HMI in a sealed-off cell has no connection through which an agent could report or a scanner could reach it.

• Old Windows versions stay in service

  According to NIST, the lifespan of an OT system can exceed 20 years, and many OT systems run operating systems that no longer receive patches. A way of checking has to cope with older Windows versions too.

What is needed is a way that only reads, installs nothing and works without a network – and produces a result that stands up as evidence.

Windows hardening checklist: what a check should cover

If you have to show Windows hardening for an audit – under IEC 62443, NIS2 or GMP, for example – you first need a list of what is checked. Expected values depend on the Windows version, the role and the plant software; Microsoft, for instance, lists different defaults for the LAN Manager authentication level depending on the role. These areas belong in the check, phrased here as questions – set the expected values with your source and the plant vendor:

• Accounts and sign-in

  Who is a local administrator, which accounts are enabled, including Guest? Is automatic logon configured – and is it justified? According to Microsoft, the password can then be stored in the registry in plain text.

• Credentials and NTLM

  Which NTLM variants does the LAN Manager authentication level allow? Is LSA protection on?

• Network, shares and services

  Is SMBv1 enabled, is SMB signing required? Which shares exist, and which services run that the plant does not need?

• Remote Desktop

  Is Remote Desktop on – and if so, only with Network Level Authentication, and for whom?

• Firewall

  Is Windows Firewall on in every profile, and which inbound rules exist?

• Antivirus

  Is antivirus running, such as Microsoft Defender Antivirus? How old are the signatures, which exclusions are set? Some plant vendors recommend specific antivirus tools; NIST advises following the vendor’s recommendations.

• Audit and logging

  What does the audit policy record, how large is the Security log, is PowerShell logged?

• Removable media and AutoRun

  How are USB storage and AutoRun for removable media configured?

• Encryption and TLS

  Is the system drive encrypted? Which SSL and TLS versions does Windows allow?

• Updates and lifecycle

  Does the Windows version still receive security updates, and when was the last one installed?

Checking with Windows’ built-in commands: secedit, auditpol, reg query

Windows ships with commands that read the security settings without installing anything. Open the command prompt with “Run as administrator” – according to Microsoft, auditpol needs a right that only administrators have by default. Change to the target folder first, for example the USB stick: without a path, output files land in the current folder.

• Security policy: secedit

  secedit /export /cfg secpol.inf /log secedit.log writes the local security policy to a text file, including account policies, security options and user rights. /mergedpolicy adds the settings from the domain; /log puts the log file into the current folder too.

• Audit policy: auditpol

  auditpol /get /category:* shows the audit policy settings for all categories and subcategories; /r gives the result as CSV.

• Single values: reg query

  reg query HKLM\System\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel reads the LAN Manager authentication level. If the value is missing, the registry simply holds nothing – which behaviour then applies has to be looked up in Microsoft’s documentation for the version and role. The exit code does not tell you whether a value is missing or could not be read: reg query only knows 0 (success) and 1 (failure).

• Group Policy: gpresult

  gpresult /scope computer /r shows a summary of the Group Policy Objects that apply to the machine; gpresult /scope computer /h gpresult.html writes an HTML report instead (/h cannot be combined with /r). This helps mainly on domain-joined machines.

Two pitfalls with reg query: for many keys under HKLM\SOFTWARE, a 32-bit program on 64-bit Windows sees its own view of the registry (Wow6432Node), Winlogon among them; the policy keys under HKLM\SOFTWARE\Policies are shared by both views. If the command prompt was started from a 32-bit program, such as a remote-support tool, a value that is actually set may appear to be missing; /reg:64 reads the 64-bit view. And with automatic logon, the Winlogon key may hold the password in plain text – query single values there, for example reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon, rather than printing the whole key.

Where the built-in commands stop:

• They give raw values, not an assessment: whether a value is right is not in the output.
• You maintain the expected values yourself – per Windows version and role, with a source.
• The evaluation is manual, for example in a spreadsheet; missing values and defaults need careful interpretation.
• Configured is not the same as effective: a policy alone does not show whether antivirus is actually running.
• The commands do not manage exceptions or approvals, and they leave no record of who collected what and when, or who signed off the result.

Central options: Group Policy, MDM, agents, network scans

• Group Policy

  In a Windows domain, Group Policy distributes settings by site, domain and organisational unit and overwrites local values at the next update. It sets expected values but does not produce a check report – gpresult only shows which policies apply.

• MDM with compliance reports

  Machines enrolled with an MDM service synchronise regularly with the management server and take over its policies; compliance policies can also evaluate the device configuration. Without a connection to the management server, none of this works.

• Agents

  An agent is a program that usually runs permanently on every machine, collects the configuration and reports to a server. Convenient for managed machines – on a plant PC, installing it is already a change, and every agent update is the next one.

• Network scans with credentials

  A scanner signs in to every machine over the network with an account and reads the configuration. That needs network access, reachable management interfaces, an account with rights on every machine – and, on a plant network, permission to scan.

For managed office IT, these are the usual options. On plant PCs without a domain, without a network or without approval for additional software they often do not fit – what remains are the built-in commands or a portable collector that reads locally and leaves the evaluation to another PC.

Keep checking and changing apart

Checking scripts and programs that compare the configuration on the machine itself with a list of expected values are available from several vendors and projects; a factual comparison with well-known ones is on the Riegel product page. Some can also apply the settings – which saves time in office IT. On a validated or accepted plant PC, every setting they apply is a configuration change – with everything that comes with it: a change request, agreement with the plant vendor, testing and possibly revalidation.

Microsoft itself says that a Windows hardening setting can break things: changing the LAN Manager authentication level may affect compatibility with client devices, services and applications, and at the stricter level, devices that do not support NTLMv2 can no longer authenticate in the domain. For OT, NIST recommends documenting, testing and approving changes before deploying them. A sensible order is therefore:

• Check read-only first and record the current state.
• Decide on every deviation: fix it, justify it as an exception, or deliberately take the rule out of scope for this role.
• Prepare changes as files, with a rollback, and agree them with the plant vendor.
• Test on a test system or a spare station, then apply them in a maintenance window through change control.
• Check again afterwards and record the new state as the approved state.

Justify and approve exceptions, compare with the approved state

Not every rule is met on plant PCs – sometimes for good reason: the HMI must come back up without a sign-in after a restart, older software needs an old protocol, the vendor does not approve a particular antivirus product. Microsoft, for example, recommends automatic logon only where the computer is physically secured and untrusted users cannot access the registry remotely. Conditions like these belong in a justified exception – not in a silent deviation that nobody can explain at the next audit.

An exception is not a ticked box but a documented decision. It names:

• the rule and the machines or groups it applies to
• the justification and the accepted value – if the value changes later, the exception should no longer apply
• the compensating measure, such as a locked control cabinet or an isolated network
• who approved it, with a reference to the change or QMS record
• how long it is valid and when it will be reviewed

This matches published guidance: for legacy OT systems that do not support a security control, NIST says compensating controls should be considered and advises documenting the approved baseline configuration of OT devices. In its guidance on the NIS2 requirements for digital services such as data centres and managed service providers, ENISA lists documented and approved exceptions to the configuration baseline, with the alternative measures in place, as an example of evidence.

Comparing with the approved state matters just as much: record how the machine was configured after commissioning or acceptance, and compare later checks with it – for example after a service visit by the vendor. That shows what has changed, even if nobody reported it. For computerised systems in GMP environments, EU GMP Annex 11 calls for periodic evaluation anyway, to confirm that they remain in a valid state.

Riegel: portable collector, offline evaluation

Riegel is our Windows hardening check for machines in plants, labs and control rooms. It separates collection from evaluation: a portable collector of about 130 KB runs from a USB stick on the plant PC, installs nothing, changes no configuration, opens no network connection and writes only its export; Windows itself records that a program ran, and gpresult can make Windows start the Group Policy Client service on demand. The evaluation happens on an analysis PC – which is also where the MSI and the analysis app (Windows 10 1809 or Windows Server 2019 and later) belong, not on the plant PC.

• Built for plant PCs

  The collector is designed for Windows 7 SP1 to 11 and Windows Server 2008 R2 SP1 to 2025 and needs .NET Framework 3.5.1 or 4.x. Where no foreign program may run, collect-builtin.cmd uses only Windows’ own commands such as secedit, auditpol and reg; --minimal starts no other program on sensitive HMIs.

• 153 rules, honest results

  Accounts, credentials and NTLM, Defender, firewall, audit and PowerShell, RDP, removable media, TLS and more. A pass needs positive evidence; what could not be read is “not checkable”, never a silent pass.

• Justified, approved exceptions

  Justification, accepted value, approving role and a change or QMS record – bound to its content, with expiry and history. If the value changes later, the finding is open again.

• Comparison with the approved state

  What changed since commissioning or a vendor visit? Changes for the worse first, then raw-value drift.

• A report to sign

  Plant report as PDF, plus Excel, CSV and an evidence pack that auditors re-check with verify – also on Linux.

• Remediation as files only

  .reg files with a rollback, GptTmpl.inf and audit.csv for the plant vendor – never applied by Riegel.

For the change request, the documentation lists which items the collector reads, which programs it starts and which traces Windows records. The catalogue is backed by ACSC, Microsoft documentation and DISA STIGs; it contains no CIS and no BSI SiSyPHuS content. Riegel supports evidence but makes no compliance claim.

Honestly: Riegel is a pre-release (0.1.2) and not code-signed yet – Windows may show a warning when Riegel’s programs are started, and the collector can only be allow-listed by its hash. There will therefore be no customer pilot on OT or validated machines until the collector is signed. Riegel has been tested on fixtures and CI runners, not yet on real Windows 7, 8.1, Server 2008 R2 or 2012 R2 machines, in a real domain, with third-party antivirus or EDR, or with real AppLocker enforcement. Without administrator rights, with --minimal or from the built-in commands, many rules cannot be decided; the report then says “Incomplete check”. Riegel is free of charge under the MIT licence. The download follows with the public release.

Our product

Riegel – Windows hardening check for plants, labs and control rooms

Check Windows hardening read-only and offline: a portable collector with nothing to install, 153 rules, justified exceptions and a report to sign – designed for Windows 7 SP1 to 11 and Windows Server 2008 R2 SP1 to 2025.

Status: Coming soon · Coming soon

More about Riegel Comparison with other checking tools

The options compared

“Depends on the product” and “depends on the solution”: features differ from tool to tool. Riegel is a pre-release (0.1.2) and not code-signed yet; there will be no customer pilot on OT or validated machines until the collector is signed.

Which option fits when?

• Looking up single values, for example after a fault or before an audit

  The built-in commands: reg query for single registry values, auditpol /get for the audit policy, secedit /export for the security policy.

• Office IT in a domain or under MDM

  Central management with its reports, plus an agent or a network scan where needed.

• Plant PC without a network or without approval for extra software

  A portable collector that installs nothing, with the evaluation on another PC – or, where no foreign program may run at all, the built-in commands. Riegel offers both, but is still an unsigned pre-release.

• Validated machine in a GMP environment

  Check read-only, record deviations as justified, approved exceptions, change things only through change control – and compare with the approved state at the periodic review.

• The plant software needs an insecure setting

  A justified exception with a compensating measure, approval and expiry date instead of a silent deviation.

• Machine builder before delivery

  Check the as-delivered state and ship the justified deviations of your own software with it; Riegel has an “as delivered” report preset for this and also runs in the factory acceptance test (FAT). Riegel is still an unsigned pre-release; there will be no customer pilot on OT or validated machines until the collector is signed.

• Windows hardening is to be applied

  Separately from checking: prepare changes as files, agree them with the plant vendor, test them, apply them in a maintenance window and check again afterwards.