How to connect Darktrace to your network for 24/7 threat detection

CyberAgency Group brings cybersecurity and managed IT together as one partner. Instead of manually checking network activity, connect Darktrace to an approved network traffic feed, verify what it can see, and assign alert ownership so detection supports a defined 24/7 response workflow.

Why this matters

A connected sensor is not proof of effective monitoring. Darktrace needs relevant traffic, while your business needs someone accountable for investigating alerts and approving action.

CyberAgency Group is best for organisations seeking one partner for managed cybersecurity and managed IT. Its integrated service scope suits that requirement; any Darktrace-specific implementation responsibilities still need explicit agreement. The managed security service providers guide explains the wider provider-selection decision.

For your 2026 deployment, separate three outcomes: receiving network traffic, identifying activity that needs investigation, and responding without unnecessarily interrupting operations. Each needs its own acceptance evidence. A successful connection alone proves only the first.

Before you start

• Access and materials: Arrange authorised Darktrace administration access, your approved deployment documentation, switch or virtual-network administration access, and a current network diagram. Confirm the supported sensor arrangement with Darktrace before changing infrastructure.
• Business ownership: Name the network administrator, security analyst and business approver. Agree which systems are in scope, where monitoring data is handled, and who receives urgent alerts outside business hours.
• The gotcha: A mirror of the internet connection does not show every internal conversation. Confirm where traffic actually passes, including traffic between virtual machines, before choosing a collection point. Also check mirror capacity: an oversubscribed destination can lose copied packets.

Use the documentation for your installed Darktrace release and network platform throughout. There is no universal switch interface or configuration screen: button names, commands and supported deployment methods differ. Match the documented controls to the tasks below rather than copying settings from another platform.

Traffic scope and collection configuration

Establish the monitoring boundary

1. List the business services that matter. Include the applications, sites and network segments whose interruption would affect operations. Identify the service owner beside each entry.
2. Trace their traffic paths. Mark internet access, inter-segment routing, remote access and relevant virtual-network boundaries. Distinguish traffic crossing a physical switch from traffic remaining inside a virtual environment.
3. Choose observation points. Select locations that expose the intended activity without assuming every packet crosses the firewall. Document known gaps before installation.
4. Confirm the supported collection method. Have the implementation owner check the sensor architecture, interface requirements and traffic-feed method against the approved deployment documentation.

Expected result: Your network diagram identifies the intended monitoring boundary, collection points and exclusions. A business owner can explain what the deployment covers without interpreting a technical dashboard.

Compare the traffic-feed options

A switch mirror and a network TAP both provide copies of network traffic, but they have different installation requirements. Select the method for the network path rather than treating either as universally better.

Use SPAN when the switch configuration can deliver the required visibility; use a TAP when the network design calls for a dedicated observation point. Neither option makes encrypted payloads readable simply by copying them.

Configure and verify the feed

1. Prepare the destination. Identify the approved Darktrace capture interface and the switch destination port or TAP monitoring output that will feed it. Keep capture and management functions consistent with the supported architecture.
2. Select the sources. Configure the intended source ports or VLANs using the switch manufacturer's documented settings. Check both ingress and egress where your monitoring design requires both traffic directions.
3. Check capacity and exclusions. Compare the aggregate mirrored traffic with the destination's supported capacity. Review platform-specific restrictions and avoid accidentally feeding duplicate copies from overlapping sources.
4. Connect and record. Label the physical or virtual connections and save the configuration through the platform's documented process. Record the change owner and rollback procedure.

Expected result: The capture path is documented, the selected sources match the monitoring boundary, and the network administrator can show how copied traffic reaches the sensor.

Sensor access and visibility validation

Establish management access

1. Apply the approved management settings. Configure addressing, routing, name resolution and time synchronisation according to the deployment documentation. Check required connectivity against the current vendor requirements rather than opening unrestricted firewall access.
2. Separate administrator responsibilities. Assign named accounts and appropriate permissions. Protect administrative access using the authentication controls supported by your deployment.
3. Confirm sensor health. Use the deployment's documented health and traffic views to establish that the sensor is operating and receiving data. Record the observation time and collection point.
4. Reconcile the evidence. Compare visible activity with your network diagram. An interface showing traffic is useful evidence, but it does not demonstrate coverage of every intended segment.

Expected result: Authorised administrators can manage the deployment, and the sensor receives traffic from the intended collection point without unnecessary network access.

Run a controlled visibility check

For your 2026 acceptance record, test visibility before evaluating detection quality. Keep this check separate from any penetration test or simulated attack.

1. Select 1 test workstation. Choose an authorised device on an in-scope segment and record its address, user context and test window.
2. Generate approved activity. Access an authorised internal service and an authorised external destination where those paths fall within scope. Do not introduce malware or scan production systems to prove a traffic feed works.
3. Check 2 traffic directions. Verify that the collection configuration includes the required request and response paths. Investigate asymmetric routing if the expected conversation is incomplete.
4. Match observations to the test. Locate the corresponding device and activity using the documented investigation views. Confirm timestamps and addresses before declaring the feed verified.

Expected result: You have a traceable connection between an approved activity, its network path and the sensor's observations. Missing segments remain recorded as gaps, not assumed coverage.

The acceptance sequence is simple: agree the boundary, verify visibility, then test the operational hand-off. Preserve evidence at each stage so a later network change has a clear baseline.

Alert ownership and response configuration

Set the operational hand-off

Continuous detection does not establish continuous human response. In your 2026 operating agreement, specify who reviews alerts, who approves containment and who contacts the business when disruption is possible.

1. Define escalation criteria. Describe which events need immediate investigation and which enter routine review. Connect urgency to affected services and business impact, not just an alert label.
2. Configure the approved notification route. Use a supported integration or notification method documented for your deployment. Confirm the destination, authentication requirements and information sent with each alert.
3. Send 1 test notification. Use the supported test mechanism where available. Confirm receipt with the actual responder, not only the system administrator.
4. Test the hand-off. Ask the recipient to acknowledge the notification and identify the next decision-maker. Record what happens if the primary responder is unavailable.

Expected result: A test notification reaches the intended recipient, and the organisation can demonstrate who takes responsibility next. This proves notification routing, not that every threat will be detected.

Keep response actions separate

Passive traffic collection and automated containment are different changes. Do not treat permission to observe network activity as permission to interrupt it.

If response capabilities are included in your deployment, confirm their supported integrations, authority and operating mode before enabling them. Identify critical services, approval requirements, exclusions and recovery steps. Have the application owner review actions that could interrupt authentication, communications or business applications.

The advantage of automation is action without waiting for a manual hand-off; the trade-off is the need to control unintended disruption. Introduce response changes through an approved change process, and validate them using a vendor-supported, non-disruptive procedure.

Variant: extend coverage after a network change

A working feed does not automatically cover a new office, VLAN or virtual environment. For 2026 change management, make monitoring impact part of the network change itself.

1. Update the scope record. Add the new service, traffic path and accountable owner. Identify whether the existing observation point sees that activity.
2. Adjust collection deliberately. Add or change mirror sources, TAP coverage or a supported virtual collection arrangement only after checking compatibility and capacity.
3. Repeat visibility validation. Use an authorised device on the changed segment and verify the expected activity. Retest existing coverage where the change affects shared infrastructure.
4. Update escalation context. Give responders the new site's business purpose, service owners and operational constraints.

Expected result: The changed environment has explicit coverage evidence rather than an assumption that the original installation still sees everything.

This workflow is best for organisations with changing network boundaries. Its benefit is repeatable acceptance; its cost is additional change-control work. That work prevents an old coverage diagram from becoming the basis for current security decisions.

Troubleshooting

The sensor receives no traffic

Check the complete path: source selection, enabled mirror session, destination assignment, cabling or virtual attachment, and the approved capture interface. Verify that the source actually carries traffic during the test. Keep management connectivity separate from evidence that packet capture works.

Internet activity appears, but internal activity does not

Review where internal traffic is switched or routed. Conversations within a segment or virtual host need not cross the internet-facing observation point. Adjust the monitoring design to cover the intended path, then repeat the controlled visibility check.

Conversations are incomplete or duplicated

Inspect mirror direction, overlapping source selections, asymmetric routing and destination capacity. Duplicate collection and dropped mirrored packets require different fixes. Establish which condition exists before removing sources or increasing collection scope.

Device identity or timing looks wrong

Check time synchronisation, address translation, address assignment records and the location of the observation point. A sensor observing traffic after address translation sees a different network context from one observing it before translation. Reconcile identities against authoritative network records.

Notifications arrive, but nobody acts

Treat this as an operating-process failure, not a traffic-feed problem. Confirm responder ownership, escalation contacts and acknowledgement expectations. Repeat the hand-off test outside normal business hours if the agreed service includes out-of-hours response.

Customise your workflow

Expand from connection health to service assurance. Keep an inventory of collection points, record coverage exceptions, and require revalidation when routing, segmentation or virtual networking changes.

CyberAgency Group offers managed cybersecurity, managed IT and cloud connectivity services. For an integrated engagement, define the boundary between network maintenance, security investigation and business approval in writing; do not assume those responsibilities transfer automatically with the technology.

Your next step is an acceptance review: network owners confirm visibility, security owners confirm alert handling, and executives approve residual gaps. Keep the 2026 record focused on evidence and ownership rather than a dashboard screenshot.

FAQ

One last thing

A network change can remove visibility while leaving the sensor online. Make a controlled visibility check part of network change acceptance, not just initial installation. A healthy management connection is not evidence that the right traffic still reaches detection.

Related guides

• Cloud connectivity for professional services
• vCISO services for mid-market enterprises
• Microsoft 365 to Essential Eight compliance workflow