Purpose
The device is where risk becomes action
Identity controls decide who may connect, but endpoints determine whether malicious code can run, credentials can be stolen, sensitive information can be copied and ransomware can spread. Laptops, desktops, mobiles, shared devices and legacy systems therefore form a critical enforcement and containment layer.
RACF-CC focuses on obtaining a trustworthy device state, enforcing a minimum protection baseline and proving that devices can be recovered. It favours measurable use of existing management, protection and collaboration platforms over an assumption that every charity can operate enterprise-scale endpoint detection and response.
What good looks like
Every supported device has a known owner and state, receives security updates, uses encryption and endpoint protection, restricts high-risk behaviour, protects credentials and can be rebuilt or have essential data recovered. Unsupported devices are replaced, isolated or formally risk-managed.
Risk picture
Where endpoint exposure accumulates
Audit without prevention
Security controls may record malicious behaviour while still allowing it to execute if protective rules never move beyond observation mode.
Unknown device state
Enrolled does not always mean compliant. Devices that stop reporting or fall outside policy weaken trust in access decisions.
Credential theft
Incomplete credential isolation and unmanaged local administrator passwords can turn one compromised device into broader identity compromise.
Encryption gaps
Lost, stolen or improperly retired devices may expose sensitive information when encryption or recovery-key handling is incomplete.
Unproven recovery
File synchronisation and backup assumptions do not demonstrate recoverability unless health, failures and restoration are monitored and tested.
Legacy platforms
Unsupported systems may be unable to run modern protections, receive patches or meet the same device baseline as supported endpoints.
Prioritised action
The RACF-CC endpoint control set
Priorities should be adjusted for clinical or care-system compatibility, workforce needs and the organisation's actual threat and device profile.
| Priority | Control direction | Why it matters | Useful evidence |
|---|---|---|---|
| First | Establish a known compliance and protection baseline for every managed device. | Unknown or inconsistent state makes endpoint trust and remediation unreliable. | Compliance, inventory, check-in and protection reports. |
| First | Encrypt supported endpoints and securely retain recovery information. | Reduces exposure following loss, theft or device retirement while preserving recovery. | Encryption status, key escrow and exception evidence. |
| First | Enable endpoint protection, tamper resistance and host firewall baselines. | Creates foundational prevention and limits unauthorised weakening of controls. | Configuration and active-device coverage reports. |
| First | Enable file protection and monitor synchronisation or recovery health. | Makes endpoint data resilience observable rather than assumed. | Folder-protection, sync-health, error and recovery-test evidence. |
| Next | Move suitable attack surface reduction controls from audit to staged enforcement. | Blocks common script, document, ransomware and persistence behaviours before they succeed. | Audit events, exclusions, pilot results and block outcomes. |
| Next | Protect credentials and manage local administrative access. | Reduces credential dumping, password reuse and escalation from a compromised endpoint. | Credential-protection configuration and local-admin reviews. |
| Next | Use device compliance and application protection in access decisions. | Prevents identity alone from making an unsafe device trustworthy. | Policy results, device risk, sign-in logs and approved exceptions. |
| Next | Isolate, restrict or replace unsupported endpoints. | Contains systems that cannot meet the supported protection baseline. | Asset register, segmentation evidence and dated risk acceptance. |
| Develop | Standardise provisioning, rebuilding and update governance. | Reduces configuration drift and shortens recovery time throughout the device lifecycle. | Deployment success, rebuild tests, update compliance and change records. |
Safe implementation
A four-phase roadmap
Phase 1 • Baseline
Make device assurance visible
- Reconcile inventories and reporting status
- Close encryption and protection gaps
- Confirm recovery-key availability
- Enable synchronisation health and error visibility
Phase 2 • Enforce
Turn telemetry into prevention
- Review attack-surface audit evidence
- Pilot high-confidence protection rules
- Integrate compliance into access decisions
- Restrict unmanaged and non-compliant access
Phase 3 • Standardise
Reduce drift and recovery time
- Adopt consistent provisioning for new and rebuilt devices
- Strengthen credential and local-admin controls
- Formalise update ownership and evidence
- Test rebuild and data-recovery procedures
Phase 4 • Modernise
Address structural constraints
- Replace or redesign unsupported dependencies
- Move legacy policy into modern management
- Improve application control where feasible
- Develop advanced detection and response capacity
Test before blocking
Preventive rules can affect scripts, macros, remote support tools and specialist applications. Use representative pilot groups, audit evidence, controlled exclusions, user communication and a rollback plan. An exclusion should have an owner, reason and review date—not become a permanent invisible gap.
Move endpoint prevention through controlled stages
Audit/report-only → pilot → validate → enforce → monitor → reviewASR rules, application controls, compliance policy and update rings need representative devices, compatibility evidence, controlled exclusions, user communications and rollback criteria. Use the Safe Enforcement Pattern →
Managing an unsupported endpoint?
Containment, constrained access, monitored use and accountable residual-risk ownership can reduce exposure while replacement is planned. Use the legacy-risk treatment guide →
Start here
Six practical first actions
Find devices with an unknown or stale state
Compare the asset register, management platform and endpoint-protection inventory; investigate devices that appear in only one source.
Close encryption exceptions
Confirm supported devices are encrypted, recovery information is available and every exception has a documented resolution or acceptance.
Confirm protection is active, not merely licensed
Measure active onboarding, health, tamper resistance, firewall state and recent reporting—not product entitlement alone.
Turn on recovery-health visibility
Identify devices that are not protecting expected folders, have stopped synchronising or repeatedly report errors.
Pilot high-confidence attack reduction
Use audit events to choose a small protection set, test with representative teams and move safely toward enforcement.
Create a legacy-device decision register
For every unsupported endpoint, record the service dependency, exposure, compensating controls, owner and replacement or review date.
Evidence and assurance
Measure enforcement and recovery
Coverage needs a denominator
A percentage is meaningful only when the active device population is trustworthy. Reconcile management, security and asset data before concluding that a high coverage figure represents the whole estate.
Residual risk and escalation
Record endpoint exposure that cannot yet be removed
What may remain unresolved?
Unsupported or intermittently connected devices, unknown management state, protection rules remaining in audit mode, application exclusions and devices that cannot meet the standard compliance baseline may persist.
Specialist care software, hardware compatibility, shared-device use, vendor restrictions, replacement cost or incomplete inventory evidence may delay full enforcement.
Isolate high-risk devices, restrict access, maintain available endpoint protection, remove local privilege, monitor use and accelerate replacement planning.
The service or application owner owns continued operational dependence, supported by endpoint administrators and governance.
Review by risk-defined frequency and after major application, operating-system, hardware, policy or supplier changes.
Known exploitation, protection no longer reporting, exception growth, failed encryption or recovery, vendor end-of-support or evidence of care-service disruption.
Recording does not equal acceptance. Unsupported endpoints and enforcement exceptions require accountable, time-bound decisions rather than indefinite technical workarounds.
Standards alignment
Research and implementation references
The implementation examples use Microsoft capabilities because they reflect the research environment. The control outcomes can also be delivered with equivalent platforms.
- NIST SP 800-53 Revision 5 — configuration, malicious-code protection, system integrity and recovery control families.
- Microsoft: Attack surface reduction deployment guide — audit, test, enforce and monitor workflow.
- Microsoft: Device compliance policies — known-state assessment and access integration.
- Microsoft: Require healthy and compliant devices — testing device-based access decisions.
- Microsoft: BitLocker recovery keys for enrolled devices — recovery-key availability for managed endpoints.
Continue the framework
Contain what an endpoint can reach
Endpoint controls reduce execution and protect the device. Domain 3 extends that containment by limiting unnecessary trust and movement between networks, sites, remote connections and sensitive services.