When a new employee receives a company laptop, the process usually feels routine.

The device arrives with the operating system installed. Standard applications are already loaded. Security tools are in place. Email, productivity software, endpoint management agents and other business tools are configured so the employee can get to work quickly.

Behind that routine process is something many organizations rely on heavily: a gold image, sometimes called a gold build or corporate image.

A gold image is the standard operating system image used to deploy laptops, desktops, servers or other devices across an organization. Instead of configuring every machine from scratch, IT teams build a baseline image and use it repeatedly. That approach is efficient, consistent and often necessary in larger environments.

But it also creates an important security question:

If the baseline image contains a weakness, how many systems now share that same weakness?

That’s where gold image penetration testing becomes valuable.

The Security Risk Hidden in Standardization

Standardization is one of the reasons gold images exist in the first place. IT teams require a repeatable way to deploy systems at scale. A consistent build helps with support, patching, software deployment, user experience and operational efficiency.

The challenge is that consistency cuts both ways.

If the image is well configured, every system deployed from it starts from a stronger foundation. If the image contains a misconfiguration, vulnerable software, weak local account settings or overly permissive control, that issue may be replicated across hundreds or thousands of devices.

From an attacker’s perspective, that creates opportunity. They don’t need to find a unique weakness on every machine. They only need to identify a repeatable weakness in the build.

At RMC, this is the kind of issue we pay close attention to during internal pentesting. Many organizations have invested significant time and resources into their endpoint security programs, but they may not have had the baseline image tested from the perspective of someone trying to break it.

That can leave a dangerous gap. A system may follow internal standards, vendor guidance or normal IT deployment practices and still contain security weaknesses an attacker can exploit.

What Gold Image Pentesting Evaluates

Gold image pentesting focuses on the security posture of the standard build before or after it’s deployed broadly across the environment.

The goal is not simply to confirm the image functions properly. The goal is to understand what a typical user, compromised user or attacker could do with a system built from that image.

Depending on the environment, testing may evaluate Windows, Linux or macOS builds. In some cases, organizations may have multiple gold images for different user groups, business units or server types. A corporate workstation image may look very different from an engineering workstation, a production server or a specialized administrative system.

In practical terms, the test asks whether the organization is deploying a secure baseline or unintentionally distributing the same weakness everywhere.

RMC may evaluate how local user and administrator accounts are configured, whether password practices create unnecessary exposure, what software is installed by default, how endpoint protection tools are configured and whether users can access or modify files, folders or settings they should not control. On Windows systems, this may include reviewing Group Policy, remote management settings, scripting controls and legacy features. On Linux systems, the review may focus on admin-level permissions, remote access settings, service configurations, file permissions and other privilege boundaries.

The specific findings vary by environment, but the larger question is the same: what risk is being built into the standard deployment?

Common Issues RMC Looks For

Some findings are straightforward. For example, an organization may have a local administrator account on every machine with the same password, or a password that follows a predictable pattern. That may have been created for convenience during setup or support, but it can become a backdoor if an attacker discovers it.

Other findings are less obvious.

For example, an organization may have strong application controls in place, but still leave an overly permissive folder or file path that allows unapproved tools to run. That type of configuration issue is not unusual, and it can undermine controls that were otherwise put in place for the right reasons.

Another common issue involves deployment scripts or setup files that are not removed from the build. If those scripts contain credentials, tokens or other sensitive information, they can create opportunities for credential exposure and lateral movement once the image is deployed across the environment.

Gold image reviews can also uncover vulnerable software that’s installed everywhere by default. If a standard utility, outdated application or management tool is present on every deployed system, then a vulnerability in that software becomes much more than an isolated issue.

The same concept applies to operating system features and legacy protocols. Some settings remain enabled because they help with compatibility or make administration easier. In a business environment, those same features can create unnecessary risk. LLMNR is one example RMC commonly sees in internal network testing. In a gold image review, the same issue takes on broader significance: if a risky protocol or legacy feature is enabled in the standard Windows image, that risk may not be limited to one workstation. It may be repeated across the entire fleet.

The same general principle applies to other legacy or convenience-based configurations. They may not look dangerous in isolation, but when repeated across an entire environment, they can create reliable paths for compromise.

Why Vendor Defaults Are Not Enough

One of the most important lessons from RMC’s pentesting work is that “standard” does not always mean “secure.”

Organizations often assume that if they followed Microsoft documentation, vendor guidance or normal deployment practices, then the resulting environment must be reasonably secure. In reality, vendors are typically building for broad functionality and compatibility. They’re not always building for the specific risk appetite of your business.

In many cases, IT teams are doing exactly what they were told to do: following documentation, supporting legacy systems, maintaining uptime and trying to avoid breaking critical operations.

But attackers don’t care whether a setting exists for a good operational reason. They care whether it can be abused.

Gold image pentesting helps close that gap by looking at the build from an offensive perspective. Instead of asking only, “Does this configuration work?” the test asks, “What could someone do with this configuration if they were trying to move beyond normal user access?”

That’s often the difference between a build that functions as intended and a build that’s truly ready to be deployed across an organization.

The Business Impact of a Weak Gold Image

The business risk of a weak gold image comes from how widely it can be replicated.

If a single deployed laptop contains a misconfiguration, that’s one issue to fix. If every laptop shares that same misconfiguration, the organization may be facing a systemic exposure. The same is true for server images, administrative workstations or specialized systems used in operational environments.

The potential impact can include easier privilege escalation, broader lateral movement, credential exposure, endpoint control bypasses and repeated vulnerabilities across business units. It can also increase remediation time and cost because the problem may not be isolated to one system. It may be embedded in the way systems are deployed.

This matters especially for organizations operating at scale. The larger the environment, the more important the baseline becomes.

It also matters in critical infrastructure and other highly regulated sectors, where endpoint compromise can create consequences beyond data loss. In environments tied to power, manufacturing, pharma, agriculture, chemical operations, healthcare or financial systems, endpoint security is connected to business continuity, operational resilience and trust.

Gold image pentesting gives leaders a way to reduce risk before it spreads.

A Better Way to Think About Endpoint Security

Many organizations test networks, applications and external exposure. Those are important areas of security testing. But the endpoint image deserves the same level of attention because it’s the foundation on which daily operations run.

A gold image review can be especially valuable when a new standard build is being rolled out, laptops or servers are being refreshed, an MSP or third party manages endpoint deployment, or security tools and hardening standards have recently changed. It can also be valuable after internal pentesting identifies repeated endpoint findings, because those findings may point back to a broader issue in the build itself.

This should not be viewed as a one-time exercise. Images change. Applications are added. Security tools are updated. Business requirements evolve. New attack techniques emerge. Even a major operating system upgrade, such as moving from Windows 10 to Windows 11, can introduce new settings, defaults or compatibility decisions that change the organization’s risk profile. A build that was reasonable two years ago may no longer reflect the environment being deployed today.

Our recommended approach is to treat gold image testing as part of a repeatable secure build process.

For business and security leaders, the starting point is simple: do we know what’s in our standard image, and has anyone tested it from an offensive security perspective?

From there, the conversation should focus on whether local accounts are configured securely, whether unnecessary services or legacy protocols are enabled, whether endpoint protections are properly configured, whether deployment artifacts have been left behind, and whether the same weaknesses are being replicated across multiple business units.

These questions help move the conversation from whether devices are being deployed efficiently to whether they’re being deployed securely.

RMC’s Take

Gold images are built to create consistency across an organization. But if the baseline has not been properly validated, that same consistency can work against the business by giving attackers a weakness they can find once and use repeatedly.

A single overlooked configuration, weak local account, vulnerable application or permissive control can become part of the standard build. At that point, the weakness is no longer confined to one device and becomes part of the organization’s standard deployment.

RMC’s role is to help organizations identify those risks before they become easiest paths through the environment. By testing the gold image from an attacker’s perspective, organizations can find and fix systemic weaknesses earlier, reduce the attack surface across endpoints and build greater confidence in the systems they deploy every day.

For organizations that rely on standard builds, the question is not whether a gold image makes deployment easier. It almost certainly does.

The better question is whether that image has been tested well enough to trust what it’s distributing.