Internal Authenticated Vulnerability Scans

Internal Authenticated Vulnerability Scans are used to identify security vulnerabilities, misconfigurations, and missing patches on systems inside the network using authenticated access. These scans provide the most accurate and comprehensive vulnerability results available in Cyrisma.

This article explains how authenticated scans work, how they are executed, what they require, and what data they collect.

What Internal Authenticated Vulnerability Scans Do

Internal Authenticated Vulnerability Scans evaluate systems from the perspective of an authorized user or administrator. By using valid credentials, the scan gains deeper visibility into the system than is possible with network-only scanning.

These scans are commonly used to:

• Identify vulnerabilities based on installed software and patch levels

• Detect missing operating system and application updates

• Identify insecure configurations and services

• Perform accurate CVE-based vulnerability detection

• Support remediation, patching, and risk prioritization

Execution Models

Internal Authenticated Vulnerability Scans support two execution models. Selecting the correct model is critical to scan success.

1) Agent-Based Scanning (Recommended)

Agent-based scanning uses a scan agent installed directly on each target system. Each system scans itself locally.

How it works

• The agent runs locally on the target

• No remote access is required

• No credentials are required for local scanning

When to use

• Systems where an agent can be installed

• Scans requiring maximum depth and accuracy

Key characteristics

• Highest accuracy and lowest failure rate

• No dependency on network permissions

• Targets without agents cannot be scanned using this method

2) Sensor-Based Scanning (Probe Scanning)

Sensor-based scanning uses a single agent to scan multiple systems remotely across the network.

How it works

• One agent acts as a sensor (probe)

• The sensor connects to remote systems using credentials

• Vulnerability data is collected remotely

When to use

• Agents cannot be installed on all systems

• Preliminary or centralized scanning is required

Key characteristics

• Requires valid credentials

• Dependent on network connectivity and permissions

• Less depth than agent-based scanning

Credential Requirements

Credential requirements depend on the execution model:

• Agent-based scans:

  • No credentials required

  • Scanning is performed locally by the agent

• Sensor-based scans:

  • Credentials are required for remote systems

  • Credentials should have administrative-level access

  • NT / NetBIOS format must be used for Windows systems

Azure AD–joined systems cannot be authenticated remotely using NTLM and must be scanned using agent-based scanning.

Data Collected

Authenticated scans collect detailed system-level information, including:

• Installed software, patch levels, and OS hotfixes

• Running processes and services

• Registry entries, scheduled tasks, and configuration settings

• Local user accounts and group memberships

• Antivirus, firewall, and endpoint protection status

• File system data, including sensitive files or misconfigurations

• Accurate CVE and patch-based vulnerability detection

Accuracy Considerations

Authenticated scans provide significantly more accurate results than unauthenticated scans because they:

• Validate vulnerabilities using installed software data

• Reduce false positives

• Identify vulnerabilities not visible over the network

• Provide deeper insight into system security posture

Sensor-based authenticated scans improve accuracy over unauthenticated scans but do not match the depth of agent-based scanning.

Prerequisites

To run Internal Authenticated Vulnerability Scans successfully:

• At least one scan agent must be deployed

• For sensor-based scans:

  • The sensor must have network access to targets

  • Credentials must be valid and properly scoped

• Endpoint protection must allow agent activity

Performance Considerations

Scan duration is influenced by:

• Number of systems in scope

• Execution model used

• Network latency (for sensor-based scans)

• Endpoint protection interference

Best practice:

• Prefer agent-based scanning where possible

• Validate credentials before large sensor-based scans

• Schedule scans during off-peak hours

Common Limitations

• Systems without agents cannot be scanned using agent-based scanning

• Sensor-based scans may fail due to credential or network issues

• Azure AD–joined systems cannot be scanned remotely

• Endpoint protection may interfere if allowlisting is not configured

Best Practices

• Use agent-based scanning whenever possible

• Use sensor-based scanning only when agents cannot be deployed

• Use dedicated service accounts with least-privilege access

• Ensure endpoint protection allowlisting is in place

• Re-run scans regularly to track remediation progress