Safeguard 4.7 default accounts: requirements and evidence

What Safeguard 4.7 asks for and why default accounts get exploited

Safeguard 4.7 requires your enterprise to deal with the accounts that vendors ship preconfigured, such as root and administrator, by disabling them or otherwise making them unusable. If you already have an asset inventory and hardening work underway, this is the Safeguard that closes the gap between "we know what is on the network" and "nothing on it still opens with a factory login." It is the only Control 4 Safeguard in the Users asset class, which reflects that the risk sits in the identities themselves rather than in the configuration of a service or device. These accounts are attractive targets for three reasons. The names are public and predictable, so an attacker does not need to discover them. Vendor default credentials are often documented or widely reused across installations. And the accounts usually carry broad privileges from the start. Because 4.7 is an IG1 Safeguard, CIS treats it as essential cyber hygiene, a baseline every enterprise should meet regardless of size or sophistication. Its cost is mostly in the verification work, not in buying anything.

The hard part is rarely the first login. Appliances, network devices and cloud images often ship with accounts that cannot be deleted, only changed, so the practical answer is to rename or lock them, replace their credentials with unique ones held in your password management process, and record the exception. Cloud images and templates can also carry default users that persist into every instance built from them, and an account disabled in the console may still exist in a local user store, a directory, or a configuration file on the device. Confirm for each asset class where these accounts live, check each place rather than trusting one, and make the check repeatable so that a new build does not quietly reintroduce them.

Which default accounts and systems fall under Safeguard 4.7

Safeguard 4.7 applies wherever a vendor ships an account with a known name or a default credential, so the scope is set by what your inventories say you run. Each card below is a scope decision that changes how much work the measurement takes and what evidence you must keep. Start from the asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1), which the CIS assessment specification lists as prerequisites for measuring Safeguard 4.7.

Operating system built-in accounts

Root on Linux and Unix, and Administrator on Windows, are the accounts most often named in this Safeguard. Decide which operating system images in your estate ship with a built-in superuser, and whether each one is disabled, renamed, given a unique password or restricted to break-glass use. Confirm the rule for each image family, since a golden image that reintroduces the account undoes the work on every host built from it.

Network devices and appliances

Routers, switches, firewalls and load balancers often ship with a factory administrator login that the vendor documents publicly. Decide whether the device supports disabling that account or only changing its password, and record the answer for each model. Where the account cannot be removed, document the compensating control, such as restricting management access to an administrative network.

Databases and middleware

Database engines and application servers create default administrative users during installation, and some ship with sample schemas or demo accounts. Decide which of these are required by the platform itself, which can be locked, and which must be renamed or given credentials generated at deployment. Check that automated installers do not recreate the defaults on every new instance.

Cloud and SaaS administrator accounts

Cloud tenants and SaaS platforms create a root or global administrator at sign-up, and that account often sits outside your normal identity provider. Decide who holds it, how it is protected, and whether it is kept for emergency use only. Confirm with each provider which account types can be disabled and which can only be secured, because the answer determines what you document.

Embedded and IoT device accounts

Cameras, sensors, printers and industrial controllers often run with fixed logins that cannot be changed through their normal interface. Decide whether each device class can be updated to a unique credential, and whether it can be isolated from general user networks if it cannot. Record devices that cannot be changed as exceptions with a named owner and a review date.

Vendor service accounts

Vendor support, monitoring and maintenance accounts are created for a supplier's own use and can be impossible to delete without breaking support. Decide whether the account can be made unusable between support sessions, whether access is enabled only through an approved request, and who approves it. Document the account, its owner and its disablement method so an assessor can trace the decision.

How an assessor tests Safeguard 4.7

This table walks through how an assessor applies the CIS Controls Assessment Specification to Safeguard 4.7, from the single metric and its six measures to the prerequisite inventories and the findings that usually come up. Use it to prepare evidence before fieldwork, and confirm sample sizes and scope with your assessor before testing begins.

Test element	What the assessor does	Evidence requested
Metric under test	Confirms the single metric of unusable default accounts and reviews each of the six measures that feed it	Written description of which default accounts exist on each asset class and how each one was handled
Prerequisite inventories	Checks that the asset inventory (Safeguard 1.1), software inventory (Safeguard 2.1) and unique password records (Safeguard 5.2) cover the population before sampling	Current asset and software inventory exports, plus the account credential baseline used to scope the test
Default account identification	Compares vendor-preconfigured accounts such as root and administrator against the accounts actually present on sampled systems	Account listings from sampled endpoints, servers, network devices and key applications, with timestamps
Disabled or unusable state	Verifies that each identified default account is disabled, renamed, locked or otherwise rendered unusable, and that the state persists	Configuration baselines, directory or local account policy settings and a current export showing account status
Sampling approach	Selects a representative sample across asset types and platforms drawn from the inventories, with more attention to privileged and internet-facing systems	Sampling rationale and the population list the sample was drawn from; confirm sample sizes with your assessor in advance
Common findings	Default administrator accounts left enabled on appliances, cloud images or applications, or accounts disabled on one platform but not its clones	Remediation tickets, updated baselines and rescan results showing the account is now unusable

How to disable or neutralize default accounts in sequence

This sequence turns Safeguard 4.7 from a policy statement into a verified state: every vendor-preconfigured account on in-scope systems is either disabled, renamed, locked or removed, with a documented exception path for accounts that must remain and recorded evidence of each change.

Build the in-scope inventory from Safeguards 1.1 and 2.1
Start from the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1). The CIS assessment specification treats these two inventories as prerequisites for measuring Safeguard 4.7, because they define which devices, operating systems, databases, network appliances and applications the check must cover. Assign each system an owner and a platform type. Done means every in-scope system appears once, with its platform and owner recorded, and the list is exported and stored with your configuration records.
Enumerate vendor-preconfigured accounts per platform
For each platform type, list the accounts the vendor ships enabled or with well-known names, such as root, administrator, default service logins, built-in database accounts and factory admin accounts on network appliances and management consoles. Use the vendor documentation for each platform, since names and defaults differ and change between releases. Export the account lists directly from the systems where possible, not from memory. Done means each platform has a reviewed list signed off by its owner.
Decide the action for each account
For every account on the list, choose one action: disable it, rename it, lock its credentials so it cannot authenticate, or remove it. Record the reason and the action in a register. Accounts that the platform cannot function without, such as some system service accounts, need a documented justification and must move to the break-glass path in the next step. Done means no vendor-preconfigured account is unclassified, and each decision names an accountable owner.
Document a break-glass path for retained accounts
Where an account must remain, define a controlled emergency access route. Store its credentials in an approved secrets vault with unique, strong values (see Safeguard 5.2), restrict who can retrieve them, and log every use. Confirm that the route works in a test before relying on it, and make sure its use triggers review. Done means each retained account has a written justification, an owner, a storage location and a tested procedure, and the register links to them.
Apply the change through configuration management
Make the decisions persistent by encoding them in your configuration management, infrastructure as code or golden image pipeline, so rebuilt or newly provisioned systems do not reintroduce enabled defaults. Test the changes first on non-production systems, and confirm the exact disable or lock procedure for each platform in the vendor documentation. Keep a change record that links to the commit or build that applied it. Done means a rebuild from the pipeline produces the same account state as the tested system.
Verify with an automated check
Run an automated configuration assessment that tests each in-scope system against the account decisions. Open-source options include Wazuh Security Configuration Assessment, which uses YAML policies largely based on CIS benchmarks and accepts custom policies, and Fleet policies, which are yes or no osquery questions that show which devices pass or fail. Write a custom check for each vendor account on the register where no existing policy covers it. Confirm coverage against your own platforms before you rely on any tool. Done means the check runs on a schedule and reports pass or fail per system.
Record the output of each step
Keep dated evidence from every step: the approved inventory, the account lists per platform, the decision register, break-glass procedures and test results, the change records, and the scan reports showing pass or fail. Assign an owner to review failures and track each one to closure. Your assessor will test whether the process produces this record, so store it in a location that is versioned and access controlled. Done means an independent reviewer can trace any system from the inventory to its current account state and its latest passing check.

Which evidence shows default accounts are unusable

Safeguard 4.7 is satisfied by proof that every vendor-preconfigured account is disabled or neutralized and stays that way. The cards below cover the artifacts an assessor will ask for, how each one stays current between audits, and where open-source tooling can generate the records.

Default account inventory per platform

This is the list of every preconfigured account on each operating system, appliance, database, cloud tenant and application in scope, with the vendor default noted for each. Build it from the asset and software inventories that Safeguards 1.1 and 2.1 produce, then confirm which accounts exist on each platform rather than relying on the vendor's documentation alone. Refresh it after every new build, upgrade or onboarding, and record who reviewed it and when. An inventory that omits a platform leaves its default accounts unmeasured.

Disable or neutralize change records

Each change that disables, renames, locks or removes a default account should have a ticket showing the account name, the method used, the approver and the completion date. Methods vary by platform, so record whether the account was disabled, given an unusable password hash, or set to a non-login shell. Keep these tickets linked to the change management system so an assessor can trace a claim to a dated approval. Review open items monthly so that no default account remains in an unfinished state.

Configuration baseline exports

A baseline export captures the state of accounts at a point in time, showing whether each default account is disabled, locked or without a usable login method. Export it from the hardening build or configuration management tool and store it under version control with a date stamp. Compare each new export against the previous one so that any re-enabled account appears as a difference. Ask the assessor which format and frequency they accept before you start collecting.

Automated scan results over time

Scheduled scans show whether default accounts remain unusable across the estate, not only on the day of an audit. Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies that are mostly based on CIS benchmarks, can be extended with custom policies, and recommend remediation for each finding. Fleet policies are osquery yes or no queries, and the policies page shows which devices pass or fail each one, which gives a per-device history. Confirm whether the shipped checks cover each default account on your platforms, and add custom checks where they do not.

Exception and break-glass records

Some platforms need a default account for recovery, vendor support or bootstrapping, and those cases must be recorded rather than silently left open. Each exception should name an owner, the business reason, the compensating controls such as restricted network access or monitored use, and a review date. Store a break-glass credential in a vault with access logged, and record each use with the reason and the approver. Review exceptions on the set date and close any that no longer apply.

Policy and standard defining the process

A written standard should state which accounts are in scope, the required method for disabling or neutralizing each type, who approves exceptions and how often the process is reviewed. It supports Safeguard 4.1, the secure configuration process, and it gives assessors the process they will compare your records against. Confirm that the standard names the platforms in scope and matches what the scans and baselines actually check. Review it on a fixed schedule and after any major platform change.

Which other frameworks use the same default account evidence

The CIS Controls Navigator for v8.1 links Safeguard 4.7 to several other frameworks: NIST SP 800-53 Rev. 5 IA-5, ISO/IEC 27001:2022 Annex A 8.2 and 8.9, SOC 2 CC6.3, and PCI DSS v4.0 requirements 2.2.2 and 2.3.1. In practice, the same proof that vendor-preconfigured accounts are disabled or made unusable can be reused across these audits. The evidence is a current inventory of the accounts that ship with each operating system, database, network device, appliance and application, a record of how each one was disabled, renamed, or set to a non-interactive state, and a recurring scan showing no default credential remains usable. Start by confirming the exact mapping text for each framework in the CIS Controls Navigator rather than relying on a summary, because mapping entries can be revised between versions.

One evidence set can serve several audits, but each framework's assessor decides whether it is sufficient for its own requirement. A PCI DSS assessor will look at the vendor default accounts in scope of the cardholder data environment and whether passwords were changed and unnecessary accounts removed. A SOC 2 auditor will test whether that control operated consistently across the review period and whether the scope matches the system description. An ISO/IEC 27001 certification body will check the Annex A 8.2 privileged access and 8.9 configuration management controls against the organization's own risk treatment decisions. Confirm with each auditor which systems they consider in scope, what sampling they expect, and whether they want the same scan output or a different format.

CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, so a Safeguard 4.7 implementation does not satisfy PCI DSS, SOC 2 or ISO/IEC 27001 by itself. It is one input to those programs. Organizations subject to a specific regulation should map their own evidence to that regulation's requirement wording with their assessor, and should not treat a CIS mapping as an official equivalence. Before the audit cycle begins, agree in writing with your assessor which artifacts they will accept and who will produce them, since the organization owns its controls and the independent auditor alone issues the report or certificate.

What meeting Safeguard 4.7 costs in money and effort

This table breaks down the cost components of meeting Safeguard 4.7, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to decide which parts your own team can carry. No prices or durations are given here because none are supplied for this Safeguard, so ask providers for a figure from a written scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down and how to keep it down
Discovery and account inventory	Internal platform or IT team, optionally an implementation partner	One-time, then recurring as platforms change	Driven by the number of platforms and identity stores. Keep it down by reusing the Safeguard 1.1 asset inventory and the Safeguard 2.1 software inventory rather than rebuilding them.
Engineering time to disable or neutralize default accounts	Internal engineers or a partner under a fixed-scope agreement	One-time per platform, with rework after major upgrades	Rises with vendor-locked accounts that cannot be removed and need workarounds. Keep it down by listing those accounts early and confirming each vendor's supported method in writing.
Configuration management changes	Internal platform team, or the partner that maintains the build pipeline	Recurring, as images and templates are rebuilt	Lower where an existing configuration management or infrastructure as code pipeline already sets account state. Higher where hosts are hand-built. Keep it down by enforcing the account state in the baseline, not by manual runs.
Automated check tooling	Self-hosted Wazuh and Fleet remove license spend for those tools, subject to their licenses. Hosting and staff time remain	Recurring, for hosting, updates and rule upkeep	Driven by how many endpoints are monitored and how many custom checks are written. Keep it down by starting from the Wazuh policies shipped mostly on CIS benchmarks and extending only where needed. Confirm license terms before deployment.
Evidence upkeep	Internal compliance or security staff	Recurring, usually on each review cycle	Driven by how often accounts change and how many systems need a dated record. Keep it down by generating the evidence from the same checks that enforce the control.
External review or testing	Independent assessor, penetration tester or implementation partner, under a written scope	Recurring, often annual or per assessment	Driven by the depth of testing requested and the number of in-scope systems. Ask for the scope, deliverables and retest terms in the quote.
Auditor sampling	Independent auditor or certification body, under its own engagement terms	Recurring, per audit cycle	Driven by how many systems and accounts the auditor samples and how well the evidence is organized. Keep it down with a clear, current account register that maps each default account to its disabling method.

Who owns Safeguard 4.7, who prepares the evidence and who assesses it

The organization owns Safeguard 4.7. Its leadership decides which vendor-preconfigured accounts stay, which are disabled or made unusable, and which exceptions are approved. The Safeguard asks for accounts such as root and administrator to be dealt with, so someone inside the enterprise must decide what "dealt with" means for each platform and who signs off on the list.

Account decisions: Maintain the written decision for each default account, including whether it is disabled, renamed, password-rotated to unusable values or kept under documented justification.
Exception approval: Approve any default account that must stay active, record the business reason, the compensating controls and a review date.
Process ownership: Run the recurring check that new assets and software releases still ship without active default accounts, and assign a named owner.
Staff and change control: Keep administrators informed of changes that could break service accounts or vendor support access.
Accountability in audits: Answer the assessor's questions and produce the decision records, even when a partner assembled them.

Check that the organization can name the owner, the approver for each exception and the schedule for reviewing the account list.

Where teams fall short on default accounts and how to close each gap

Safeguard 4.7 looks simple on paper, but most failures come from scope, persistence and visibility rather than from the act of disabling an account. The cards below cover the gaps assessors and operators meet most often, and the practical fix for each.

Disabled on servers only

Teams often disable root and the default administrator on Linux and Windows servers, then stop there. Network appliances, hypervisors, storage arrays, cloud consoles and SaaS admin tenants keep vendor-preconfigured logins that still work. Start from the asset inventory required by Safeguard 1.1 and the software inventory from Safeguard 2.1, then list every platform that ships a default account, including management interfaces that are not servers. Check each one and record the result.

Vendor accounts left undocumented

Some vendor accounts cannot be removed because the product or support model depends on them. When these stay in place without a record, nobody can explain why they exist, who holds the credentials or what they are allowed to do. The fix is a register for each retained account that names the product, the business reason, the credential custodian, the compensating control such as a unique and rotated password or restricted network access, and the review date. An auditor will ask for this register first.

Hardening lost at rebuild

A disabled account on a running system is not durable. When a golden image, template, container base or infrastructure-as-code module is rebuilt or updated, the vendor default often returns. Make the change part of the build: put the disable step in the image pipeline or configuration management code, version it, and run a check after every rebuild. Confirm that your image pipeline rebuilds from source rather than from a snapshot that carries old state.

Break-glass accounts with no owner

Emergency accounts are sometimes the only way back into a system, so they are kept enabled and forgotten. An unowned break-glass account is a default account in practice. Assign a named owner, store the credential in a controlled vault with access logging, require its use to be approved and recorded, and review it on a fixed schedule. Confirm with the assessor how they expect the account to be evidenced, since the measurement focuses on whether unusable default accounts are in place.

No check between audits

A default account disabled during a project can be re-enabled by a patch, a restore or a manual change, and no one notices until the next assessment. Between audits the state is unknown. Run a recurring configuration check that reports whether default accounts are disabled or unusable on each in-scope asset. Wazuh Security Configuration Assessment and Fleet policies can both express this kind of yes or no question, though you should confirm the exact checks against your platforms before relying on them.

Incomplete inventory sets the wrong scope

If the asset inventory omits hypervisors, out-of-band management cards, network gear or SaaS tenants, the measurement covers only the systems that were found. The result looks compliant while default accounts remain on systems nobody counted. Reconcile the inventory against cloud accounts, network discovery, identity provider records and procurement lists before you set the scope. Record the reconciliation so the scope decision can be explained to an assessor.

How much work does Safeguard 4.7 take, and can we do it ourselves

Can our own team implement Safeguard 4.7 without outside help?

Yes, many teams can handle 4.7 in house, because the work is mostly inventory, configuration review and disabling or renaming accounts. The harder part is repeatability: someone must know every platform that ships vendor accounts, change each one through a controlled process and keep proof that it stayed that way. Teams with a current asset inventory, a software inventory and a configuration management process usually need less help than teams that have to build those first. A partner is most useful when the scope spans many platforms, when platforms are locked to vendor accounts, or when the team lacks time to write the evidence trail.

What drives the effort for Safeguard 4.7 up or down?

Effort rises with the number of platforms, the number of vendor-preconfigured accounts on each one, and how many of those accounts cannot be disabled without breaking an application. Weak configuration management adds work because each default account has to be found again and checked by hand. Effort falls when the platforms share a baseline, when accounts are documented in one place and when a single standard covers the disabling method. Ask any partner to list the platforms, versions and vendor accounts in a written scope before quoting, since that list is what the price should follow.

Do we need a partner for the asset inventory or the automated checks?

You do not need a partner to create an inventory, but you may want help if the inventory is incomplete. Safeguard 4.7 depends on the asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) because those tell you which platforms exist and which vendor accounts they ship with. For automated checks, open-source tools such as Wazuh's Security Configuration Assessment can run policies against endpoints, and Fleet can ask yes or no osquery questions about devices. Setting up these checks, writing custom policies and tuning them to your environment is a common scope item for an implementation partner, and it should be defined in writing before work starts.

What will an assessor ask for to verify Safeguard 4.7?

An assessor will expect evidence that the default accounts on each in-scope asset were identified, then disabled or made unusable, and that the result can be reproduced. In practice that means an account list per platform, the method used for each account, change records and a current check showing the account is unusable. The CIS Controls Assessment Specification defines the measures for this Safeguard, so review it before the assessment starts. Independent auditors or certification bodies decide whether the evidence is sufficient, and DeployOpen prepares systems and evidence without issuing any report.

How often should we check for re-enabled or new default accounts?

Check at least when a platform is installed, upgraded or added to the inventory, and on a recurring schedule that your risk assessment supports. Vendor updates can recreate accounts, and new software can bring new defaults, so a one-time review is not enough to show the state persists. Automated checks can run on the schedule you set and record the results, which makes the recurring cost mostly a matter of reviewing exceptions. Confirm the frequency and the owner of each review with your assessor before you commit to it.

How does Safeguard 4.7 relate to the other Control 4 Safeguards?

Safeguard 4.7 covers vendor-preconfigured accounts, which sit alongside the other hardening work in Control 4. Safeguard 4.1 requires a documented secure configuration process that the default account handling should follow, and Safeguard 4.6 covers how assets are administered, which affects how accounts are used after they are disabled. Safeguard 4.8 covers unnecessary services, so an account and a service may be reviewed in the same pass. Safeguard 5.2 requires unique passwords, which matters for any account you keep, and the mappings to other frameworks listed for 4.7 can help you show overlap with other programs.

What should we ask a partner for in a quote for Safeguard 4.7?

Ask for a written, fixed scope that lists the platforms and versions in scope, the vendor accounts expected on each, the method for disabling or rendering each account unusable, and the evidence that will be delivered. Also ask what is one-time work, such as the initial remediation and check build, and what recurs, such as scheduled checks or retainer support. Confirm who owns each account decision, how exceptions are approved and what the partner will not do, such as issuing an audit opinion. Most DeployOpen engagements are fixed-scope, and a quote follows from that written scope.

How DeployOpen scopes, hardens and prepares evidence for Safeguard 4.7

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so default account handling is built into the platforms themselves. We prepare the systems and evidence for Safeguard 4.7, while the organization keeps ownership of its controls and any independent assessment is performed by others.

How we scope

The written scope lists every platform, appliance and operating system in which vendor default accounts must be reviewed.
Scope names the inventory sources that feed the measurement, such as the asset inventory under Safeguard 1.1 and the software inventory under Safeguard 2.1.
Scope states who owns each default account decision and which accounts are excluded, with the reason recorded in writing.

How we build

We identify vendor-preconfigured accounts such as root, administrator and service defaults on each in-scope system during build.
We disable, rename or lock default accounts where the platform allows it, and record any account that must remain for operational reasons.
We check that break-glass access uses unique, separately managed credentials, aligned with the password work under Safeguard 5.2.

How we hand over

We deliver a register of default accounts with the status of each (disabled, unusable or justified exception) and the date of the last check.
We hand over configuration checks that can be rerun, so the organization can show that default accounts remain unusable after changes.
We document the procedure for reviewing default accounts when new platforms or vendor updates are added to the environment.

How we support

Fixed-scope engagements agree scope, deliverables and timelines in writing before any work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, which covers default accounts on platforms added later.
Before the evidence goes to an independent assessor, confirm with that assessor which artifacts they accept for Safeguard 4.7.