SC-26 Decoys: requirements and evidence

What SC-26 decoys asks for and why no baseline includes it

When an assessor or an overlay has selected SC-26, the team has to show that decoys exist, that they are placed deliberately, and that anyone who touches them generates a record someone reviews. SC-26 asks the organization to include components designed to be the target of malicious attacks, so that those attacks can be detected, deflected and analyzed. A decoy is not a production asset with a few extra logs turned on. It is a component whose only legitimate purpose is to be probed, so any interaction with it is suspicious by default. SP 800-53B does not assign SC-26 to any security or privacy baseline, so an organization meets it only because it selected it through tailoring or because an overlay or agreement requires it.

That baseline status explains why the control is hard to justify. Nothing in the low, moderate or high baselines forces a decoy, so the case has to rest on a specific threat reason, such as repeated scanning of a particular network segment, credential theft aimed at a service account, or a sector threat report describing a technique the organization needs to observe. Without that reason, a decoy becomes a maintenance burden: someone must build it, keep it believable, keep it patched without making it an actual foothold, and decide what happens when it fires. Confirm with the assessor or the overlay owner exactly which determination statements apply to SC-26 in your release before committing to a design, since SP 800-53A Release 5.2.0 assesses it through three determination statements and expects examination of design documentation, configuration settings and audit records.

The practical decision is therefore whether the threat reason is strong enough to justify the decoy and its monitoring. If it is, document the placement, the purpose of each decoy, the alerting path into the monitoring stack and the review owner, so that the design documentation and audit records an assessor examines match what the system actually does. If the threat reason is weak, the better answer is to record that SC-26 is not selected for the system and to show the related detection controls in SC-7, SI-4 and RA-5 instead, after confirming with the authorizing official that this is acceptable.

Which systems and scoping choices decide the SC-26 decoys work

SC-26 is not assigned to any SP 800-53B baseline, so the work begins with a deliberate decision to select it and a clear boundary around what the decoys are for. The cards below cover the choices that most change the evidence an assessor will ask for, from where decoys sit to who acts on what they capture.

Network zones that host decoys

Decide which zones or segments receive decoys, such as a DMZ, a segment holding administrative interfaces, or a segment with sensitive databases. Each placement attracts a different kind of attacker activity. Document the zone and the reason for it in the system design documentation, because an assessor will examine that documentation first. Confirm that decoy traffic cannot reach production services except through defined and monitored paths.

Internet-facing or internal placement

Internet-facing decoys see opportunistic scanning and automated attacks, which produce high volumes of noise but reveal external techniques. Internal decoys show what an attacker does after a foothold, which is often the more useful signal for detection and response. Choose one or both deliberately, and record the rationale. An internet-facing decoy also needs its own exposure review, because it is reachable by anyone.

Teams that receive and act on alerts

A decoy only supports SC-26 if someone is accountable for its alerts. Name the security operations or incident response team that triages decoy events, the on-call path for after-hours alerts, and the escalation route to incident handling. Confirm that these roles appear in the incident response plan. Without named owners, the decoy produces logs that no one reviews, and that gap is easy for an assessor to find.

Separation of decoy data from production

Decoy records, credentials and files must not match real production data, and they must not be copied from it. Mixing the two risks exposing real information to an attacker and can also poison the monitoring picture. Decide how decoy content is generated, where it is stored, and who can access it. Test that decoy hosts hold no credentials that authenticate to production systems.

Alert pipeline and log handling

Decide where decoy events go after capture: a sensor, a SIEM, or a log platform. Suricata's EVE JSON output and Wazuh's alert files are examples of formats that can carry these events into review. Define retention, time synchronization and access to the event store, since these details support both the analysis and the evidence an assessor will ask for.

Third-party hosted decoys and managed monitoring

Hosted decoy services and managed monitoring providers move part of the boundary outside the organization. Review where the decoy runs, what data it captures, who can read those records, and how the provider handles incidents and notifications. Put these terms in writing and include the provider in the scope of the assessment. The organization still owns the control, so the provider's reports do not close the question alone.

How an assessor tests SC-26 decoys

This table maps the three SP 800-53A determination statements for SC-26 to the examine, interview and test methods an assessor uses, along with the evidence each one produces. Read it as a checklist of what to prepare before an assessment and what typically causes a finding. The main takeaway is that a decoy only counts if its design, configuration, and alert records show it operating and being reviewed.

Assessment element	What the assessor does	Evidence that passes
Determination statement 1: decoys are included in the system design	Examines system design documentation to confirm decoy components are part of the documented architecture, with stated purpose and placement.	Architecture diagrams and design documents naming each decoy, its network location, and the detection or deflection goal it serves.
Determination statement 2: decoys are configured to detect, deflect and analyze attacks	Examines system configuration settings and their documentation, then interviews the staff who run them about how decoy activity is captured.	Exported configuration for each decoy, logging settings, and documentation linking each setting to the detect, deflect or analyze purpose.
Determination statement 3: decoy activity is recorded and available for analysis	Examines system audit records for decoy interactions and checks that records include timestamps, source details and the decoy involved.	Sample audit or alert records showing decoy hits, with a documented triage path that shows someone acted on them.
Interview questions for system and security staff	Asks who owns each decoy, how often its alerts are reviewed, and what happens when a decoy is touched outside business hours.	Named owners, a documented review cadence, and consistent answers across staff that match the records.
Live test by triggering a decoy	Tests by interacting with a decoy from an authorized test source and confirms that the event reaches monitoring and generates an alert.	A test record showing the trigger, the alert or log entry produced, and the response ticket or notes from the reviewer.
Common finding: decoys that exist only on paper	Finds the design document lists decoys that are not deployed or are disabled in configuration.	Asset inventory or configuration export matching the design document, reviewed on a set schedule.
Common finding: alerts that nobody reviews	Finds decoy alerts in the logs with no triage record, acknowledgement or follow-up.	Documented review workflow, assigned responders, and closed-out records for each decoy alert.
Common finding: decoy logs missing from analysis tools	Finds decoy events stored on the host but not forwarded to the platform used for review.	Confirmed log forwarding for each decoy, shown in the analysis platform for a sample period.

Implementing SC-26 decoys in sequence

This sequence takes SC-26 from a threat-driven decision to a tested, documented decoy capability that an assessor can trace from design to evidence. Each step produces an artifact the organization owns, so the decoys stay useful after any implementation partner leaves.

Define the threat reason and decoy types
Start by writing down why the organization wants decoys: which adversary behaviors it expects to see, which assets an attacker would target, and what the decoys should reveal or deflect. From that reasoning, choose decoy types such as a low-interaction service emulator, a decoy host, or a decoy credential store, and record why each type fits the threat. The output is a short design document signed by the system owner and security lead. The step is done when every decoy type traces to a named threat and an owner, and the document states that SC-26 is selected through tailoring because no SP 800-53B baseline assigns it.
Place decoys on segments chosen in scoping
Map the decoy types to the network segments and system boundaries already defined in scoping, so decoys sit where an attacker moving through the environment would plausibly pass but where no legitimate user should ever connect. Placement must respect the boundary and segmentation design documented for SC-7, so that decoys do not create unplanned paths into production systems. The output is a placement diagram and an addressing record showing each decoy, its segment, and the traffic it is expected to receive. Confirm the placement with the team that owns network architecture before anything is deployed.
Configure decoy telemetry and logging
Configure each decoy to record connection attempts, authentication attempts, commands and file activity to a central log store, with time sources aligned to the organization's authoritative clock. Decide which fields are captured, how long records are retained, and who can read or alter them, consistent with the audit controls the organization already runs. Where a network sensor is part of the design, such as an intrusion detection system that writes EVE JSON output, document which record types are exported and where they land. The output is a configuration baseline file for each decoy and a logging specification that an assessor can compare against the running settings.
Route alerts to a named review queue
Connect decoy events to the alerting pipeline and send them to a named review queue with a documented owner, a backup owner, and an escalation path. Set severity rules so that any interaction with a decoy, which should be rare in legitimate operations, opens a case rather than sitting unread in a log store. If the organization uses a SIEM or a detection platform such as OpenSearch Security Analytics or Wazuh, record which rules or detectors match decoy events and how alerts reach the queue, including notification channels. The output is an alert routing record that names the queue, the owners, and the test that proves a decoy event reaches a person.
Write the analysis and containment procedure
Write the procedure the review team follows when a decoy fires: how to triage the event, confirm whether it is a true interaction or a misconfiguration, preserve the decoy's logs, analyze the attacker's technique, and decide on containment such as isolating a source address or disabling a credential. Link the procedure to the organization's incident response plan so decoy findings enter the same case handling, reporting and lessons-learned process. Assign who may authorize containment on production systems. The output is a written, versioned procedure with an approval record, and the step is complete when the incident response owner has reviewed it.
Run a controlled test event
Trigger a planned interaction with each decoy from an authorized test source, then follow the event through logging, alert routing, triage and containment exactly as the procedure describes. Record the time each stage completed, what was missed or misrouted, and what changed in the configuration or procedure as a result. Keep the test scope agreed in writing and make sure no production system is affected. The output is a test record with the event evidence, the findings and the corrective actions, which is the artifact an assessor will most likely ask to see when testing whether the decoys detect, deflect and analyze attacks as intended.

Which evidence shows SC-26 decoys is working

An SC-26 assessment tests whether decoys exist, are placed deliberately, and produce alerts that someone reviews and acts on. The six artifacts below connect those claims, and each one should be refreshed from the live system before an assessment rather than reused from an earlier cycle.

Design document naming decoy purpose

The design document states why each decoy exists, which attack technique it is meant to attract, where it sits in the network and which detection pipeline receives its events. Assessors use it as the reference point for the examine method, so each decoy should appear with an owner, a placement and a stated purpose. Refresh it whenever a decoy is added, moved or retired, and record the review date on the document itself. Check that the placement described matches the current network diagram, not the one from the original deployment.

Configuration exports from decoy hosts

Export the running configuration of each decoy and of the sensor that watches it, including listening services, emulated services, logging targets and the rules that decide which traffic reaches the decoy. Exports show whether a decoy is actually reachable on the intended segment and whether its logs leave the host. Store exports with a timestamp and a hash so an assessor can confirm they were not edited afterward. Re-export before each assessment, because a configuration change made after the design document was written is the most common gap assessors find.

Alert samples from the review system

Provide real alert records from the system that receives decoy events, such as Suricata EVE JSON output forwarded to a log platform or Wazuh alerts written to alerts.json. Each sample should show the source, the decoy that was touched, the timestamp and the rule that fired. Samples prove the detection path works end to end, not only that a decoy exists. Pull samples from the assessment period itself, and tell the assessor which ones are test events.

Records of reviewed and closed alerts

A decoy only deflects or reveals anything if a person or workflow acts on its alerts. Keep a register that links each decoy alert to its reviewer, review time, disposition and any incident or ticket it created. Closed alerts marked as benign need a short reason, such as a scanner that was authorized and documented. Assessors commonly sample this register to confirm that alerts are triaged rather than accumulating unread. Confirm with the organization's own incident process how long these records must be retained.

Test event with its outcome

Run a controlled test that touches a decoy from a source the organization has authorized, then record the time of the test, the expected alert, the alert that actually appeared and the response taken. A test shows that the chain from decoy to alert to reviewer works at the time of assessment, which configuration files alone cannot prove. Document any failure, its cause and the fix, because a clean first run is less convincing than a documented repair. Run the test in the period close to the assessment and keep the test plan with it.

Change records for decoy updates

Every decoy added, reconfigured, moved or retired should have a change record that names the requester, the approver, the reason and the validation performed afterward. Change records show that decoys are maintained under the organization's configuration management process rather than adjusted informally. Compare the change log against the configuration exports, since a mismatch means an untracked change. Confirm with the organization's change board which changes need approval before they are made to security tooling.

What meeting SC-26 decoys costs in money and effort

This table lists the cost and effort components of running SC-26 decoys, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations are published for this control, so use the drivers to frame quote requests and internal budgeting.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Decoy platform or licenses	Vendor (commercial decoy product) or no license fee for self-hosted open-source components	Commercial: usually recurring subscription or support. Open source: none for the software itself	Number of decoy types and sensors, vendor tier, support terms. Ask for licensing basis in writing
Engineering time for placement and configuration	Internal platform or security engineers, or an implementation partner under a fixed-scope agreement	One-time, with periodic rework when the network changes	Number of network segments, integration with existing logging, and how many decoys are placed; define scope before work starts
Analyst time to review decoy alerts	Internal SOC or security operations staff	Recurring	Alert volume, how many decoys are monitored, and whether alerts are routed to a single queue with clear runbooks
Integration with detection tooling	Internal engineers or partner, for example routing decoy events into a SIEM or Wazuh and OpenSearch pipelines	One-time build, recurring tuning	Number of log sources, rule quality, and whether alerts map to existing incident response procedures
Evidence upkeep	Internal compliance or security staff, who keep configuration records, design documentation and audit records current	Recurring	Frequency of network or decoy changes and how well configuration is versioned and documented
External testing or review	Independent testers or reviewers, paid by the organization	Usually recurring on a schedule or per engagement	Scope of testing against decoys, whether tests are added to red team or penetration test work, and how findings feed back into design
Assessor sampling time	Independent assessor, paid by the organization	Recurring with each assessment cycle	Number of decoys and related records the assessor samples, and how clearly the evidence is organized before the assessment starts
Open-source tooling license spend	No license fee for OPNsense (BSD-2-Clause), Suricata (GPL-2.0-only), OpenSearch (Apache-2.0) or Wazuh (GPL-2.0-only); staff and hosting still cost money	Hosting and staff effort are recurring	Self-hosted deployment removes license spend, but operating, patching and tuning remain internal or partner effort

Open-source tools that produce SC-26 decoy evidence

SC-26 is satisfied by decoy components that attract attackers, so the evidence an assessor sees is the record of what the decoys caught and how the organization responded. The tools below do not create decoys on their own. They collect, classify and correlate the network and host events that show whether a decoy was touched, which is the material an assessor will review against the determination statements.

OPNsense intrusion detection

OPNsense includes a built-in intrusion detection and prevention system that runs Suricata with rulesets such as Emerging Threats and Abuse.ch. It can alert on or block matching traffic and send alerts to syslog in EVE JSON format. For SC-26, check whether traffic addressed to decoy addresses or decoy services falls within the monitored interfaces, and confirm with the vendor and your own configuration how the platform distinguishes decoy interactions from general scanning. Retain the alert records that show the decoy was touched.

Suricata EVE JSON records

Suricata writes EVE JSON records for rule match alerts, anomalies, flows, and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, along with file information, dropped packets and engine statistics. Those records show the attacker's protocol behavior against a decoy, which supports the analysis part of SC-26. The output can be split into separate files for log management tools, so decide early which record types leave the sensor and how long each is kept.

OpenSearch Security Analytics findings

OpenSearch Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, alerts can go to channels such as Slack or email, and a correlation engine links findings across log types in a correlation graph. Confirm that decoy hosts and decoy log sources are onboarded, and write a custom Sigma rule for each decoy so its interactions produce a finding.

Wazuh rules and alert files

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. Custom rules can flag any event from a decoy host, and the ATT&CK mapping helps show which technique the attacker attempted. Confirm the agent coverage on decoy systems, because an unmonitored decoy produces no evidence.

Who owns decoys, who builds them and who assesses them

Your organization owns SC-26 in the sense that matters to an assessor: the decision to deploy decoys, the reason for them, and the process that turns an attacker touching a decoy into a response. SC-26 is not in any SP 800-53B baseline, so the first question your team must answer is whether the control was selected at all, through tailoring or an overlay, and why. The selection rationale belongs in the system security and privacy plan, approved by the people accountable for the risk.

Threat reason: Document which attacker behaviors the decoys are meant to detect, deflect or analyze, tied to your threat model and to the systems they sit near.
Risk decision: Record who accepted the residual risk of decoys, including the risk that a decoy is misread as production or leaks its own network position.
Alert review: Name the staff who review decoy interactions, the hours they cover and how a decoy alert differs from routine noise.
Response procedure: Define containment steps, escalation paths and the link to your incident response plan, and rehearse them.
Configuration ownership: Keep the decoy inventory, placement and change records under your own change control.

Before accepting any partner work, confirm that your own staff can explain the threat reason and run the response procedure without the partner in the room.

Where SC-26 decoys programs usually fall short

Decoys only satisfy SC-26 when they serve a stated purpose, produce alerts someone acts on, and stay in a configuration an assessor can trace. The gaps below tend to appear together: a decoy goes live without a documented reason, its alerts land in a shared queue, and nobody tests whether it still fires. Each card names one gap and the step that closes it.

Decoys with no documented purpose

A decoy deployed without a written objective cannot be tested against one. Record which attacker behavior each decoy is meant to detect, deflect or analyze, the system it protects and the owner who approves it. An assessor examining system design documentation will look for this link between the component and the threat it addresses. Check that each decoy in the inventory maps to a stated purpose, and retire any decoy that cannot be tied to one.

Alerts routed to nobody

A decoy that fires into an unmonitored mailbox or log file detects nothing in practice. Define the alert destination, the on-call role that receives it and the response expected within the incident process. Wazuh and OpenSearch Security Analytics can forward alerts to channels such as email or chat, but the routing rule and its recipient still have to be configured and reviewed. Confirm the path end to end before counting the decoy as implemented.

Decoy traffic mixed into production monitoring

When decoy hits land in the same index as production events, analysts cannot tell benign scanning from real intrusion, and decoy noise distorts detection metrics. Separate decoy telemetry at the source, for example by writing Suricata EVE JSON records to their own file or index, and tag decoy events so correlation rules can filter or escalate them deliberately. Document the separation so an assessor can see how decoy data is kept distinct.

No test event proving detection

Deploying a decoy does not show that it detects anything. Schedule a controlled test that interacts with the decoy the way an attacker would, then record the timestamp, the alert generated, the recipient and the analyst action. Keep the test result with the decoy's configuration record so an assessor examining audit records can trace the event from interaction to response. Repeat the test after any change to the decoy or its logging path.

Decoy configuration drifting without change records

Decoys are often adjusted quickly during an incident, such as a new banner, a new port or a new credential, and those edits rarely reach the change log. Bring decoy images, rules and logging settings under the same configuration management process as production systems, with version control and an approval record for each change. Periodic comparison of running configuration against the approved baseline shows whether the decoy still matches what was documented.

Decoy findings not linked to incident response

A decoy alert that never reaches the incident process produces no lessons and no updated defenses. Map decoy alert types to the incident response plan, define when an alert opens a case, and record how findings feed back into boundary rules and threat hunting. SC-26 also covers analyzing attacks, so keep captured indicators and attacker techniques in the case record and share relevant ones with the teams that maintain SC-7 boundary rules and SI-4 monitoring.

How much does SC-26 decoys cost to meet, and how long does it take?

Is SC-26 decoys required by any SP 800-53 baseline?

No. SP 800-53B does not assign SC-26 to the low, moderate, high or privacy baseline, so it applies only when an organization selects it through tailoring or an overlay. FedRAMP's Rev5 baselines also do not require it at Class B, C or D. Your contract, authorizing official or regulator is the source that decides whether it is in scope, so confirm that before budgeting. Once selected, the control is marked as implemented by the system, which means the effort lands on your system design and configuration. Ask your assessor to confirm the selection in the system security and privacy plan.

How much effort does SC-26 decoys take to meet?

The effort depends on how many decoys you deploy, where they sit and how much of their output feeds your monitoring. No supplied source gives a dollar figure or duration for this control, so treat any number you see elsewhere with caution. The main cost drivers are the number of decoy systems, the network zones they cover, the depth of analysis you commit to and the alert handling process your staff must run. Ask any vendor or partner to break the quote into design, build, integration with monitoring, testing and documentation, and to state which parts recur, such as tuning and review.

Can our team implement SC-26 decoys without an outside partner?

Yes, if your staff already run network security monitoring and can build and maintain systems that look like production assets without exposing real data. The work is mostly design, deployment and log handling rather than specialist tooling. Open-source options such as Suricata-based detection, OpenSearch Security Analytics and Wazuh can ingest and alert on decoy activity, but you still need people to decide what the decoys imitate, how alerts are triaged and how findings reach incident response. A partner is most useful when the team lacks capacity or wants an independent design review. The organization always owns the control and its evidence.

What does our staff need to provide for SC-26 decoys?

Expect to supply people and documentation more than budget. Typically you need a network or security architect to define decoy placement relative to your boundary protections, a monitoring analyst to own alert triage, and a system owner who approves the design and keeps it in the system security and privacy plan. Assessors will look for system design documentation, configuration settings with their supporting notes and audit records showing decoy activity was captured and reviewed, so the people who maintain those records must be named. Confirm these roles early, because gaps in ownership are a more common delay than technical work.

How long does SC-26 decoys take before an assessment?

No supplied source gives a duration, so the honest answer is that the timeline depends on scope, environment and staffing. Plan in phases: agree scope and placement, build and integrate the decoys with your logging and alerting, run them long enough to produce audit records and test that alerts reach a human, then document the design and evidence. Change control and approval cycles often take longer than the technical build. Ask a partner to commit to milestones in a written, fixed scope, and ask your assessor which evidence they expect to see, since that determines how much operating history you need before the assessment window.

Which parts of SC-26 decoys are usually outsourced?

The most commonly outsourced parts are the initial design, the build of decoy systems in your own infrastructure and the integration with logging and alerting. Implementation partners such as DeployOpen can plan, deploy and document these components inside your cloud accounts, data centers or air-gapped networks. The organization keeps ownership of the control, decides what the decoys are for, and runs day-to-day analysis or contracts that work separately. Independent assessors remain the only parties who test the control and issue findings. Ask any partner to state in writing which deliverables they hand over and which remain with your team.

What should we ask a partner for in an SC-26 decoys quote?

Ask for a written scope that names the systems, network zones and number of decoy components in the design. Request a line-item breakdown covering design, deployment, integration with your monitoring stack, testing, evidence packaging and handover, with each item marked as one-time or recurring. Ask how alerts are routed and who triages them, which open-source components are used and their licenses, and what support or tuning retainer applies after go-live. Confirm that the partner prepares evidence but does not issue any audit report or attestation, and ask your assessor to review the evidence plan before work begins.

How DeployOpen scopes and prepares SC-26 decoy evidence

DeployOpen plans, deploys and documents decoy components inside your own infrastructure when SC-26 is selected through tailoring or an overlay. The organization owns the control decision, and an independent assessor decides whether the evidence meets SP 800-53A.

How we scope

Confirm with you whether SC-26 is selected in your tailored baseline or overlay, since no SP 800-53B baseline includes it.
Define which network segments, hosts or applications the decoys cover and which detection and analysis outcomes they must support.
Record the scope, deliverables and timelines in writing before work starts, because engagements are fixed-scope.

How we build

Deploy decoy components in your own cloud accounts, data center or air-gapped network, using self-hosted open-source platforms.
Route decoy alerts into your log pipeline and detection tooling, such as Wazuh or OpenSearch Security Analytics, and test that matches are recorded.
Test each decoy against the SP 800-53A examine objects, including design documentation, configuration settings and audit records.

How we hand over

Deliver system design documentation and configuration baselines that show where each decoy sits and why it was placed there.
Provide exported audit records and alert samples that demonstrate detection, deflection and analysis of test activity.
Document the decoy runbook and assessment mapping so your assessor can trace each determination statement to evidence.

How we support

Offer ongoing support and upgrades for decoy platforms as a retainer, if your scope requires it after handover.
Repeat decoy testing when configurations or network boundaries change, and update the documentation to match.
Coordinate with your independent auditor or assessor, who alone issues any assessment report or attestation.