Safeguard 13.5 remote asset access control

How safeguard 13.5 remote access control changes what a VPN login means

A VPN login or remote sign-in proves who the user is. It does not prove that the laptop or phone making the connection is healthy. Safeguard 13.5 asks the enterprise to manage access control for assets that connect remotely, and to decide how much access each asset receives based on three things: whether it has up-to-date anti-malware, whether it complies with the enterprise's secure configuration process, and whether its operating system and applications are up to date. The question shifts from "is this person authorized?" to "is this person authorized on a device we trust right now?" An unpatched or misconfigured home computer with valid credentials can otherwise reach internal systems, file shares and administrative interfaces as if it were a managed asset.

The reason this safeguard is harder than it reads is that the check depends on data that many organizations do not yet have in usable form. To decide whether a remote device is compliant, the enterprise must already know which devices exist (the asset inventory in Safeguard 1.1), what a compliant configuration looks like (the secure configuration process in Safeguard 4.1), and which authorization systems grant remote login (the inventory in Safeguard 6.6). The CIS Controls Assessment Specification treats those three as prerequisites for measuring 13.5. If any of them is incomplete, the posture decision has nothing reliable to act on, and the remote access gateway ends up making policy against stale or guessed data.

Safeguard 13.5 complements the VPN requirement in Safeguard 12.7, which concerns secure remote access itself. Read together, the two ask for a secure tunnel and a healthy endpoint at the same time. The safeguard applies to IG2 and IG3 enterprises only, not IG1. Before scoping work, confirm with your team which remote access paths exist (VPN, zero trust gateway, virtual desktop, cloud admin consoles) and which of them can enforce a device posture decision. Ask your identity and endpoint teams to show which signals they can pass to the gateway today, and where a remote session can still succeed when the posture data is missing.

Which remote assets and teams fall under safeguard 13.5

Safeguard 13.5 applies to remote enterprise assets at IG2 and IG3, and its result depends on how completely the enterprise knows which devices connect and through which paths. The cards below cover the scoping decisions that change the work, from connection paths and personal devices to contractors and mobile endpoints.

Devices as the asset class

Safeguard 13.5 sits in the Devices asset class, so the scope is physical and virtual endpoints such as laptops, desktops, servers used by administrators and mobile phones, not user identities or cloud subscriptions. Confirm which endpoint types your remote population includes before you size the check. Servers that administrators reach from outside the network are often missed because they are not treated as user devices. Record each asset type explicitly so the assessor can trace the population back to inventory.

Remote connection paths into enterprise resources

Every path that reaches enterprise resources from outside the network needs to be listed: VPN concentrators, remote desktop gateways, zero trust access proxies, and direct access to cloud consoles and management APIs. Each path can enforce a different posture check, or none at all. A single unmonitored path can make the coverage metric misleading, because the assets using it never pass through the authorization system being measured. Map paths to the systems they reach before deciding where posture checks apply.

Unmanaged and personal devices

Personal laptops, home computers and bring-your-own-device phones that reach enterprise resources are the hardest population to measure. An enterprise cannot confirm anti-malware status, configuration compliance or patch level on a device it does not inventory. Decide whether such devices are allowed at all, and if they are, whether they receive limited access without a posture result. Ask the assessor how they will treat access granted to devices that were never inventoried.

Contractor and third party devices

Devices owned by contractors, service providers and managed service partners often connect through the same remote paths as employee equipment. Their owners control the patching and anti-malware settings, so the enterprise must decide whether to require enterprise-managed endpoints, a posture attestation, or a separate restricted path. Contract terms and the service provider controls in Control 15 should state which standard applies. Confirm how these devices appear in the inventory before the posture check runs on them.

Mobile devices and tablets

Phones and tablets that open email, collaboration tools or internal web applications are remote enterprise assets whether or not they run a VPN client. Their anti-malware status, operating system version and configuration are controlled by mobile device management or by the platform itself, which changes how the posture data is gathered. Identify which mobile platforms are supported and which access paths they can use. Treat each mobile access path as a separate scope item in the inventory.

Prerequisites that define the population

The assessment specification treats Safeguards 1.1, 4.1 and 6.6 as prerequisites for measuring 13.5. Safeguard 1.1 provides the detailed asset inventory that defines which remote assets exist, Safeguard 4.1 provides the secure configuration process that defines compliance, and Safeguard 6.6 provides the inventory of authorization systems that decides access. If any of the three is incomplete, the 13.5 result cannot be trusted. IG1 organizations are not assessed against 13.5, but they should still know which remote devices reach their systems.

How an assessor tests safeguard 13.5 and what they ask for

The table compares the two metrics the CIS Controls Assessment Specification uses to score Safeguard 13.5, what an assessor tests under each, the evidence they request and the findings that usually appear. Read it as a checklist for proving both that remote access is gated by posture and that the gate covers every remote asset.

Metric and assessor focus	Evidence requested	Common findings
Authorization System Compliance: whether authorization systems that allow remote login are configured properly	Configuration exports of the VPN, zero trust gateway or remote access broker, showing the posture condition attached to remote login	Remote login allowed by an authorization system that has no posture condition at all
Authorization System Compliance: how the enterprise defined a properly configured system	Written definition of compliant posture covering anti-malware status, secure configuration and operating system and application patch level, with the reasoning behind each threshold	Assessor cannot find a documented definition, so the threshold is left to the individual administrator
Coverage: share of remote enterprise assets that sit behind a compliant authorization system	Remote asset list reconciled against the enterprise asset inventory (Safeguard 1.1), with the authorization system each asset uses	Remote assets outside the inventory, including personal or contractor devices that connect but are never recorded
Coverage: assets that bypass the posture check through a second path	Network diagrams and firewall rules showing every route to internal resources from remote networks	Legacy remote access tools, direct port forwards or cloud access paths that skip the gateway
Prerequisite linkage: whether the secure configuration process (Safeguard 4.1) and authorization inventory (Safeguard 6.6) feed the posture check	Posture policy mapped to the configuration baseline and a list of authentication and authorization systems in scope	Posture policy references a baseline that no longer matches the current configuration standard
Exceptions: whether assets allowed to connect despite failing posture have an approved, time-limited justification	Exception register with asset, failed check, named owner, approver, expiry date and compensating control	Exceptions with no owner or no expiry, or exceptions granted by default for unmanaged devices
Evidence currency: whether posture results are current when the assessor samples them	Recent posture check logs or reports, and the process showing how failing devices are blocked or remediated	Posture data that is weeks old, or failed checks that were logged but never acted on

How to implement the posture check in the order that produces evidence

This sequence turns Safeguard 13.5 from a policy statement into a working posture check, with each step leaving an artifact an assessor can sample. It starts from the inventories the Safeguard depends on and ends with a recurring review of how much of the remote population the check actually covers.

Confirm the asset and authorization system inventories
The security or IT operations team confirms that the detailed enterprise asset inventory (Safeguard 1.1) lists every device that connects remotely, and that the inventory of authentication and authorization systems (Safeguard 6.6) lists every system that grants remote login, including the VPN, zero trust gateway and any remote desktop broker. Each remote-capable device is tagged with its owner and asset class. The output is a reconciled inventory extract, with the date it was reconciled and the named owner, that an assessor can sample against the remote login logs. The step is done when no remote login path or remote device sits outside the inventory.
Define the secure configuration and patch baseline
The configuration owner uses the secure configuration process (Safeguard 4.1) to set the baseline a remote device must meet before access is granted. The baseline covers three conditions named in the Safeguard: anti-malware is installed and its signatures are current, the device follows the documented secure configuration, and the operating system and applications are patched to the minimum level the organization has approved. Each threshold is written as a testable value, such as a named anti-malware product and the required signature freshness, not as a general statement. The output is an approved baseline document with version and approval record, which becomes the test specification for every later step.
Connect posture signals to the remote access authorization system
The platform team connects the posture data source to the remote access authorization system, so that the decision to allow login reads the device's compliance state at the time of connection. Typical sources include an endpoint management or osquery-based agent, which can answer yes or no policy questions about a device and show which devices pass or fail each policy. The integration configuration, the list of checks and the log of posture decisions are saved as artifacts. Confirm with the remote access product's vendor that the posture check can be enforced at login, not only reported, because some products only report. The step is complete when a test login from a non-compliant device is denied by the authorization system, not merely flagged.
Set the grant, limit and deny rules
The access owner writes the authorization policy in three tiers that match the Safeguard's logic: full access for devices that meet the whole baseline, limited access for devices that meet some conditions, and denial for devices that fail the anti-malware or patch thresholds. The limited tier should name the specific resources it reaches, such as a web mail portal rather than internal file shares. Each rule is written as a policy object in the authorization system, with its source, destination and posture condition. The output is the exported rule set and a change record, which an assessor can compare with the baseline from step two to confirm the rules match the stated thresholds.
Test with compliant and non-compliant sample devices
The test team prepares a small set of sample devices: at least one that meets every condition, one that fails anti-malware, one that fails configuration, and one that runs an unpatched operating system. Each device attempts remote login, and the expected outcome for each tier is recorded before the test. The results, including the authorization decision log entries and screenshots or exports of the posture status, form the test evidence. Any mismatch between expected and actual results is logged as a defect, fixed and retested. The step is done when every sample device produces the expected outcome and the test record is signed by the person who ran it.
Run a recurring review of coverage
The security team runs a recurring review that measures the two metrics the assessment specification uses for Safeguard 13.5: the share of properly configured authorization systems that allow remote login (Authorization System Compliance), and the share of remote enterprise assets covered by compliant authorization systems (Coverage). The review compares the remote login logs against the asset inventory to find devices that connected without a posture decision or through an unlisted authorization system. Findings open tickets with owners and due dates set by the organization. The output is a dated coverage report with both metrics, the exceptions list and the remediation record. Ask your implementation partner to confirm that the review cadence and report format match what your assessor will request.

Evidence that shows remote assets are checked before access

Safeguard 13.5 is only as credible as the records behind it. The six artifacts below show an assessor what the posture rules are, which assets they apply to, how each access decision was made, and what happens when a device fails. Keep each one current between audits with scheduled exports and change records, not screenshots taken the week of the assessment.

Authorization system configuration

The exported policy set from the remote access gateway, VPN concentrator or zero-trust broker, showing the posture conditions that gate login: anti-malware status, secure configuration process compliance, and operating system and application patch level. An assessor checks that these conditions are enforced, not just documented, and that the export matches what is running. Schedule a monthly export to version control and keep the change record for every edit to a rule.

Remote asset inventory with posture status

A list of every asset permitted to connect remotely, tied to its owner, its posture result and its last check time. This list feeds the coverage calculation the CAS uses for Safeguard 13.5. Assets that connect remotely but are missing from the inventory are the most common gap, so reconcile this list against the detailed asset inventory from Safeguard 1.1 on a fixed schedule.

Login decision logs

Sample logs showing each connection outcome: allow, limit and deny. A limit decision, where an asset gets reduced access because it is partly out of posture, is the one most often missing from evidence packs. Confirm with your gateway vendor that the platform records all three outcomes with the posture result attached, and export a representative sample for each quarter.

Anti-malware and patch reports

Reports from the endpoint protection and patch tools, filtered to the remote asset inventory rather than the whole estate. The assessor compares these reports with the posture results that the access gateway used, so mismatched device identifiers or stale check-in dates will show as failures. Keep the report date, the query used and the device count alongside each export.

Exception records with approval and expiry

Each exception that lets a non-compliant asset connect, with the business reason, the named approver, the compensating control and an expiry date. Open-ended exceptions are a finding in most reviews. Store the register in a ticketing or GRC system, review expiring items weekly, and retain the approval trail for the full audit period.

Test records for non-compliant devices

Records from deliberate tests in which a device with out-of-date anti-malware, a configuration drift or a missing patch attempts remote login. The expected result is a deny or limit decision, and the record shows the actual result, the timestamp and the remediation ticket. Run these tests after every posture rule change and on a set schedule, because they prove the rules work end to end.

What meeting safeguard 13.5 costs in money and effort

This table breaks the cost of meeting Safeguard 13.5 into its components, showing who is paid, whether each cost is one-time or recurring, what pushes it up and how to keep it down. Use it to structure a quote request, since no price list applies and every figure depends on your device estate and access paths.

Cost component	One-time or recurring	What drives it up	How to reduce it
Posture tooling or licenses (endpoint management, anti-malware, patch reporting, authorization system capabilities)	Recurring, usually per device or per seat under vendor terms	Device count, number of remote access platforms that must enforce posture, and separate licenses for each capability	Confirm which signals your existing endpoint, anti-malware and patch tools already expose before buying new licenses
Open-source posture tooling (for example Fleet policies or Wazuh configuration assessment)	Software license spend is typically nil, but hosting and upkeep are recurring	Number of endpoints to query, policy count, and the infrastructure to run the server and agents	Self-host inside your own infrastructure and budget for the operating and upgrade effort it creates
Engineering time to integrate posture signals into the access decision	One-time for integration, with recurring effort for changes	Number of authorization systems (VPN, zero trust gateway, identity provider) that must consume posture results	Start with one remote access path, then extend the same posture policy to others
Configuration and policy definition (anti-malware status, secure configuration baseline, operating system and application currency)	One-time to define, recurring to revise	Number of device types, operating systems and exceptions, plus the depth of the secure configuration process required by Safeguard 4.1	Reuse the baselines from Safeguard 4.1 and CIS Benchmarks rather than writing criteria from scratch
Prerequisite inventories (Safeguards 1.1, 4.1 and 6.6)	One-time build, recurring maintenance	Unmanaged or unknown devices and authentication systems that have no inventory entry	Clear unmanaged devices before scoping, since every unknown device adds review work
Evidence upkeep (metric records for Authorization System Compliance and Coverage, exception logs, access decision records)	Recurring	Frequency of collection, number of remote paths, and manual screenshots versus exported reports	Automate exports from the posture and access tools and keep a single exception register
External review or testing of remote access controls	Recurring, often annual or per change, if you buy it	Number of remote paths in scope, number of exceptions, and whether testing covers bypass attempts	Scope tests to the posture decision points and retest after material changes
Auditor sampling and assessment support	Recurring with each assessment cycle	Number of devices and remote sessions sampled, and how cleanly evidence is organized	Ask the auditor which sample populations they will draw and prepare evidence to match them
Unmanaged or bring-your-own devices	Recurring, as exceptions require review	Share of remote devices outside management, contractor devices, and personal devices with access	Limit remote access to managed assets and document any exceptions with compensating controls

Which open-source tools can produce posture evidence for remote assets

No single open-source tool proves that a remote asset meets the posture bar in Safeguard 13.5, but several can produce pieces of the evidence. The access decision depends on three attributes: current anti-malware, compliance with the enterprise secure configuration process, and an up-to-date operating system and applications. For the configuration attribute, Wazuh Security Configuration Assessment (GPL-2.0-only) is the most direct candidate. It scans monitored endpoints against YAML policies that are mostly based on CIS Benchmarks, can be extended with custom policies, checks files, directories, registry keys and running processes, and recommends remediation. Its scan results can be exported as a record of which endpoints passed or failed each policy at a given time, which is the kind of point-in-time evidence an assessor will ask for. Confirm that the policies you run match the configuration baseline your own secure configuration process (Safeguard 4.1) defines, because a passing scan against a different baseline does not show compliance with yours.

Fleet (MIT) policies answer yes or no questions about enrolled devices using osquery queries, and its policies page shows which devices in each fleet pass or fail each policy. This is a practical way to express checks such as whether disk encryption is on, a host firewall is enabled or a particular security agent is running, and to show current posture state for managed laptops and phones. Fleet can only assess what its agent can see, so confirm which anti-malware and patch-level signals your operating systems expose to osquery before treating a policy as a patch-level check. For the network side, OPNsense (BSD-2-Clause) rules pass, block or reject traffic by source, destination, port and protocol, and can log each rule match for review in the live log view. Those logs document which remote access paths were permitted or denied, which supports the access-logging side of the decision, but they do not tell you anything about the health of the device behind the connection. Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It defends against attacks such as SQL injection, cross-site scripting and code injection, so it belongs to application protection rather than to posture checking. It does not assess whether a remote laptop has current anti-malware or patches. Before relying on any of these tools, confirm in your own environment which anti-malware and patch signals each one reads, how often it refreshes, and whether results can be retained for audit. Also review each license (GPL-2.0-only, MIT, BSD-2-Clause and Apache-2.0) with your legal team, since licensing terms govern how you may redistribute or modify them.

Who owns the posture check and who can help prepare it

Your organization owns Safeguard 13.5. The access decision belongs to you: which remote assets may connect, what counts as compliant anti-malware, configuration and patch status, and what happens to an asset that fails. The CIS Controls Assessment Specification measures this safeguard against authorization systems you operate, so the inventory and authorization records must come from your own systems of record.

Authorization policy: Define the minimum posture for remote access, including anti-malware currency, adherence to your secure configuration process and an up-to-date operating system and applications.
Exception approval: Decide who may approve a non-compliant asset, for how long and with what compensating control, and record each decision.
Prerequisite inventories: Maintain the asset inventory (1.1), the secure configuration process (4.1) and the authentication and authorization inventory (6.6) that the assessment treats as prerequisites.
Grant or deny decisions: Own the operational decision to block a device, and the people accountable for responding when a device is removed from access.
Evidence ownership: Retain the outputs of posture checks and exception records as your own records.

Before engaging anyone, confirm that these owners are named and that the policy exists in writing.

Where remote access posture checks usually fall short

Safeguard 13.5 only works when the posture check and the access decision share one source of truth about each device. The gaps below tend to appear where the asset inventory, the authorization system and the compliance data are maintained by different teams and never reconciled.

Remote assets missing from inventory

A laptop that connects over VPN but never appears in the asset inventory cannot be measured, because the assessment specification relies on the detailed inventory from Safeguard 1.1 as a prerequisite. Start by comparing authorization system login logs against the inventory for the last 30 days of remote sessions. Any device that connected but has no record should be added or blocked until it is registered. Ask your team which discovery sources feed the inventory, and confirm that remote-only and contractor devices are among them.

Login allowed without posture condition

Many authorization systems grant remote login on credentials alone, with posture checked later or never. Safeguard 13.5 asks that the amount of access depend on whether the asset meets its requirements, so the posture condition must sit inside the access policy itself. Review each remote access policy and confirm that it names an anti-malware, configuration and patch condition that must pass before a session is granted. A policy that reads only user group membership fails this test.

Posture data not tied to device identity

Anti-malware status and patch levels often come from an endpoint tool whose device records do not match the identifiers the VPN or identity provider uses. The result is that a passing report may belong to a different machine, or to none at all. Confirm that the endpoint management platform and the authorization system share a stable device identifier, such as a certificate or a hardware-bound ID. Test by enrolling a known device and checking that its posture record appears under the same identity used at login.

Undocumented posture exceptions

Teams often grant temporary exemptions for a device that is out of date, such as a machine waiting on a vendor driver. When these exceptions are made by phone or chat and never recorded, assessors cannot tell whether access was a decision or an error. Require each exception to name the device, the failed condition, the approver, the business reason and an expiry date. Keep the register with the configuration and patch records so the exception list can be reviewed alongside the posture data.

No recurring coverage calculation

Safeguard 13.5 is measured with a coverage figure: the share of remote enterprise assets covered by compliant authorization systems. A one-time review of the posture policy does not show whether that share is holding. Set a recurring job, owned by a named person, that divides compliant remote assets by total remote assets from the inventory and records the result. Ask your implementation partner or internal team to confirm that the numerator and denominator come from the same inventory snapshot.

No test of noncompliant devices

A posture policy is only proven when a device that should fail is shown to be refused. Many organizations test only compliant machines, which proves nothing about the blocking rule. Maintain a small set of test devices with deliberately disabled anti-malware or an outdated patch level, and attempt a remote login from each one at a fixed interval and after every policy change. Record the denied result as evidence. Confirm with your authorization system vendor how it logs a denied session, because that log is the artifact an assessor will ask for.

Questions buyers ask before they hire help for safeguard 13.5

Can we meet Safeguard 13.5 in-house, and what does it take?

Yes, many organizations do this in-house, provided they already have the foundations the assessment specification expects. Safeguard 13.5 asks you to decide how much access a remotely connecting asset gets based on its anti-malware status, its compliance with your secure configuration process and whether its operating system and applications are up to date. The CIS Controls Assessment Specification lists Safeguards 1.1, 4.1 and 6.6 as prerequisites, so you need an asset inventory, a documented secure configuration process and an inventory of your authentication and authorization systems before the check means much. Your team then needs to connect those signals to the remote access gateway. Ask an outside partner only if those prerequisites are missing or your engineers lack capacity to build and test the policy logic.

How much effort is the posture check compared with the VPN work in 12.7?

The posture check is usually the smaller of the two efforts when the VPN is already in place, but it depends on how many device states you need to evaluate. Safeguard 12.7 concerns securing remote access through a VPN or equivalent, while 13.5 adds the decision about what an asset may reach once it connects. The posture work consumes most of its time in data collection: reliable inventory, patch status and configuration checks across every device type that connects. Ask any quote to separate the VPN configuration from the device posture integration, and to list which device platforms and posture signals are in scope.

How long does a Safeguard 13.5 engagement take?

The duration is whatever the written scope agreed before work starts, because DeployOpen works on fixed-scope engagements with scope, deliverables and timelines confirmed in writing. The main drivers are the number of remote access paths, the device types that connect, the state of your asset inventory and how many posture signals you must check. Ask for milestones that name the gateway, the device classes and the evidence each milestone produces.

Do IG1 organizations have to meet Safeguard 13.5?

No. CIS Controls v8.1 places Safeguard 13.5 in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 organizations still need the essential cyber hygiene Safeguards that cover inventory, secure configuration and remote access control, so the remote access posture check is a next step once that baseline is in place. Confirm your Implementation Group against the CIS Implementation Groups page before you scope the work.

How is the Coverage metric calculated for Safeguard 13.5?

Coverage is the share of remote enterprise assets that are covered by compliant authorization systems. You divide the number of remote assets that the compliant authorization systems actually cover by the total number of remote enterprise assets, which means your asset inventory must be complete for the figure to mean anything. The companion metric, Authorization System Compliance, measures the share of properly configured authorization systems that allow remote login. Confirm the exact measure definitions and data inputs in the assessment specification, and agree with your assessor how they will count remote assets and which systems they treat as authorization systems.

What will an assessor sample when they test Safeguard 13.5?

An assessor typically samples remote connections and the evidence behind them, and checks whether access decisions followed the posture rules you documented. Expect requests for the remote access gateway policy, the anti-malware and patch status recorded for a sample of connecting devices, the secure configuration baseline those devices were checked against, and logs showing both allowed and denied sessions. The assessor will also check the prerequisite inventories. Confirm the sample size and evidence list with your chosen assessor before you collect anything.

What can an implementation partner do for the audit, and what can it not do?

An implementation partner can plan the posture policy, configure the gateway and endpoint tooling, document the rules and prepare the evidence an assessor will request. DeployOpen works on self-hosted open-source platforms inside your own infrastructure, and its tools can produce evidence such as Wazuh Security Configuration Assessment results, Fleet policy pass or fail records and OPNsense rule logs. DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor or certification body can do that. Your organization remains the owner of its controls and its compliance decisions.

How DeployOpen works on this

DeployOpen plans and prepares the systems and evidence behind Safeguard 13.5 Access control for remote assets inside your own infrastructure. We do not decide compliance outcomes or issue reports; your organization owns the control, and an independent assessor reaches its own conclusion.

How we scope

Engagements are fixed-scope, with the remote access paths and asset populations for 13.5 agreed in writing before work starts.
The written scope names which authorization systems, VPN or remote access gateways and asset groups are in and out of the 13.5 review.
We confirm prerequisites from Safeguards 1.1, 4.1 and 6.6 are in place, since the assessment specification relies on them.

How we build

We configure posture checks so access depends on anti-malware status, secure configuration compliance and operating system and application patch level.
Wazuh Security Configuration Assessment can check endpoints against YAML policies, including CIS-based policies, to feed configuration evidence.
Fleet policies, written as osquery questions, can show which devices pass or fail each access-relevant check, and we test those results against known devices.

How we hand over

Documentation covers the posture rules, the enforcement points and how each rule ties to the Authorization System Compliance and Coverage metrics.
We provide evidence runbooks that show where each record comes from, how often it is exported and who reviews it.
Handover includes a walkthrough with your security and IT teams so they can explain the configuration to an assessor.

How we support

Ongoing support, upgrades and continuous testing of remote access controls are available as a retainer after handover.
We can re-run posture checks after OS, VPN or endpoint agent upgrades so evidence stays current between assessments.
Independent auditors and certification bodies, not DeployOpen, issue any report or certificate. Confirm their evidence expectations early.