A company laptop has antivirus installed. Is that enough to call it secure? What if encryption is off, updates are overdue, the user has unrestricted administrator access, or the device stopped reporting last month?
A secure configuration baseline defines how devices should be configured. Monitoring checks what is actually happening. Access controls determine whether a device should be allowed to reach particular resources.
These practices can support SOC 2 and CMMC readiness. The work begins with a clear standard, appropriate implementation, and evidence—not a green status icon alone.
What is a secure device baseline?
A baseline is an approved set of configuration requirements for a type of device and its role. Workstations, servers, phones, and specialized equipment may need different standards.
Use recognized guidance and platform recommendations as starting points, then evaluate the settings against your risks, applications, hardware, and obligations. CIS Control 4 emphasizes establishing and maintaining secure configurations for enterprise assets and software.
Record the baseline version, scope, owner, implementation method, verification method, and approved exceptions.
Configure, verify, and control access are separate jobs
| Job | Purpose | Example |
|---|---|---|
| Configure | Apply the settings the organization selected. | Enable disk encryption and the host firewall. |
| Verify | Check supported settings and actual device status. | Review encryption state, patch status, and reporting freshness. |
| Control access | Use identity and device signals in resource-access decisions. | Require an approved device meeting defined conditions before permitting access to a supported application. |
A configuration profile can fail to apply. A compliance policy may check only selected conditions. An access policy may cover some applications and leave other paths unaffected.
Do not assume every baseline setting is continuously evaluated by the device’s compliance engine. Match each important requirement to a verification method and follow up on errors, missing data, and conflicts.
Hardening areas to evaluate
The following are practical review areas, rather than a universal checklist that guarantees compliance:
| Area | What to define and verify |
|---|---|
| Supported software | Supported operating systems and applications, update deadlines, and handling of end-of-life systems. |
| Encryption | Where encryption is required, its configuration, recovery-key protection, and recovery procedures. |
| Host firewall | Applicable profiles, approved rules, exceptions, and the actual running state. |
| Screen locking | An inactivity limit appropriate to the device, environment, and applicable requirements. |
| Privileges | Standard-user access, separate administrative access, and controlled elevation for approved tasks. |
| Local administrator credentials | Unique managed credentials where applicable, rotation, authorized retrieval, and logging. |
| Endpoint protection | Supported security software, active protection, policy health, updates, and response ownership. |
| Browsers and applications | Approved software, extension controls, protective settings, and unnecessary features. |
| Removable media | Permitted devices, restrictions, encryption, and approved exceptions. |
| Firmware and boot protection | Applicable hardware capabilities, secure boot settings, firmware maintenance, and verification. |
A management tool may report a hardware condition without being able to enable it remotely on every device. Define a remediation process for equipment that cannot meet the standard.
Require approved, compliant devices—where supported
A practical objective is: require approved, compliant devices before allowing access to company applications and data, where supported.
Specify what “approved” and “compliant” mean. Define covered users, devices, applications, access methods, exclusions, stale-status handling, and remediation timing. Test the access decision from the clients your employees actually use.
Device-based controls require compatible management, identity, applications, and authentication paths. They do not automatically protect every legacy application, local file share, or Ethernet jack.
NIST’s Zero Trust Architecture explains why network location or company ownership alone should not establish trust.
Read our related article on asset inventory, BYOD, and network admission.
How does this support SOC 2?
SOC 2 evaluates controls against the relevant Trust Services Criteria. It does not prescribe a universal device-hardening settings list or require one particular management product.
CC7.1 concerns detecting configuration changes that introduce vulnerabilities and susceptibility to newly identified vulnerabilities. Its points of focus include defined configuration standards and monitoring for deviations. Depending on the control design, related access and protection controls can also support CC6.1, CC6.3, CC6.6, and CC6.8.
These are illustrative relationships, not a claim that enabling one setting satisfies an entire criterion. Management should define the control and preserve evidence of implementation and operation. Reference: AICPA Trust Services Criteria.
Explore BCS SOC 2 readiness and gap assessment support.
Can this also support CMMC Level 1 and Level 2?
Yes, but the two levels have different requirements. Under 32 CFR 170.14, Level 1 uses the FAR basic safeguards, while Level 2 uses NIST SP 800-171 Revision 2.
CMMC Level 1
Device controls can contribute to limiting access to authorized users and devices, restricting external connections, correcting flaws, and maintaining malicious-code protection. The applicable safeguards are in FAR 52.204-21.
The Level 1 baseline does not explicitly require every hardening measure listed in this article. Do not present a particular encryption product, screen-lock duration, or management platform as a universal Level 1 requirement.
CMMC Level 2
Level 2 has more explicit configuration-management requirements. Examples in NIST SP 800-171 Revision 2 include baseline configurations and inventories (3.4.1), secure configuration settings (3.4.2), and tracking and reviewing changes (3.4.3). Other requirements address least privilege, session locking, malware protection, and protection of CUI.
Map each implemented control to the relevant requirements and assessment objectives. Where cryptography protects CUI confidentiality, evaluate the applicable FIPS-validation requirement; a generic “encryption enabled” result is not enough to establish it.
A device marked compliant by a management platform is not a CMMC compliance determination. Scoping, documentation, personnel, physical safeguards, provider responsibilities, and other requirements still need evaluation.
Explore our CMMC gap assessment and implementation services.
Monitor drift and resolve exceptions
Configuration drift occurs when actual settings move away from the approved standard. A user changes a setting, an application introduces an exception, or a device misses a policy update.
For each finding, identify the affected asset, expected setting, observed state, severity, owner, and corrective action. Recheck after remediation. Approved exceptions should have a business reason, appropriate authorization, review date, and compensating measures where appropriate.
Also monitor the management system itself. An offline device with a month-old green result should not be treated as current proof of protection.
Plan product interactions and recovery
Define which tool owns each setting. Multiple platforms may coexist, but overlapping patch, antivirus, firewall, or configuration policies need coordination to avoid conflicting instructions.
Endpoint detection and response is not synonymous with antivirus. Determine the active protection components and product prerequisites before enabling dependent features. Pilot changes on representative devices and test business applications, peripherals, sign-in, and recovery.
Cloud folder synchronization can support file protection, but it does not by itself establish a complete recovery plan. Define recovery objectives, retention, backup coverage, administrative protections, and restoration testing separately.
Who approves the standard?
IT or a qualified provider can propose and implement a baseline. Business management retains accountability for approving the standard, delegated authority, risk decisions, and exceptions.
An example policy statement to adapt is:
Company devices are configured according to approved secure configuration standards appropriate to their role and applicable requirements. Assigned personnel implement the standards, verify relevant settings, investigate deviations, and document corrective actions and approved exceptions. Supported access controls restrict company-resource access using defined identity and device conditions. Management approves the standards and delegates implementation responsibilities.
Document the actual tools, scope, review intervals, and responsibilities in supporting procedures. Avoid promising controls that have not been implemented.
What evidence helps?
- Approved baseline versions and records of review and changes.
- Device inventory reconciled with management and endpoint-protection coverage.
- Policy assignments, deployment results, errors, and configuration reports.
- Compliance checks showing what was evaluated and when.
- Access-policy scope, exclusions, and authorized test results.
- Patch, encryption, firewall, and privilege records relevant to the control.
- Remediation tickets, verification, and approved exceptions.
Screenshots can support evidence, but a single green dashboard should not replace coverage checks or records over time. Protect credential and recovery-key information when preparing evidence.
Secure configuration support in Austin and Houston
Business Communication Solutions helps businesses define device standards, implement agreed safeguards, review coverage, and organize readiness evidence. We can work alongside internal IT and existing providers.
Related resources: security monitoring tools, security awareness training, and BCS cybersecurity services.
Austin: 512-257-1433 Houston: 281-815-8784
Discuss your device baseline and readiness needs with BCS.
What do you think?
Could your business explain its device security standard—and demonstrate which devices meet it today? Are you relying on a policy, a dashboard, or a verified process for keeping the standard in place?