How to set up the MITRE ATT&CK connector in OpenCTI
A threat intelligence team cannot tag reports with ATT&CK techniques or link vulnerabilities to patch priorities until the reference data sits in the same graph. OpenCTI loads MITRE ATT&CK through a dedicated connector, and connectors run as separate workers alongside the platform. The setup therefore has two jobs: make the platform accept the connector's writes, and make the connector reach the platform and the message infrastructure it depends on.
The CAPEC, CVE and CISA KEV connectors follow a similar pattern, but their names, configuration keys and availability must be confirmed in the OpenCTI connectors repository for the version you deploy. Do not copy a connector configuration from an older guide or a forum post. Confirm the release line you run as well. OpenCTI uses date-based version numbers, and regular releases and LTS releases follow different support rules, so the connector configuration you test should match the platform build you intend to keep in production.
Before you start, decide where the connector will run, which platform account it will use and who owns its schedule. Confirm that the connector host can reach the platform URL, the RabbitMQ broker and the search backend that OpenCTI uses. Create a dedicated platform account with only the access the connector needs, generate its API token, and give the connector a unique identifier so its imports can be traced in the platform. Keep the token in your secrets manager, not in a configuration file committed to source control.
After the first start, check the connector status in the platform's connector view, then confirm that ATT&CK tactics and techniques appear in the knowledge graph. Review worker logs and queue depth for backlog during the initial import. Schedule a check after each ATT&CK update, because technique revisions and deprecations change what analysts should tag against. Assign an owner to approve connector updates, since analysts will rely on this reference layer when they classify reports and indicators.
What the OpenCTI platform needs before connectors run
The MITRE ATT&CK, CAPEC, CVE and CISA KEV connectors only write to OpenCTI when the platform beneath them is ready. Each item below is a dependency, sizing rule, network path or credential to settle before the first import run, because a gap in any of them usually appears as stalled or failed connector jobs.
Elasticsearch or OpenSearch index
OpenCTI relies on a search engine, either Elasticsearch 8.0 or later or OpenSearch 2.9 or later. Choose one before installation and confirm the version against the deployment overview for the OpenCTI release you plan to run. Large ATT&CK and CVE imports create many linked objects in a short window, so check that the cluster version and its configuration can absorb that load. Ask Filigran or your architect whether switching engines after go-live is supported.
Redis, RabbitMQ and object storage
OpenCTI requires Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO. RabbitMQ carries the messages that workers consume for asynchronous writes, so it sits directly on the import path. Object storage holds uploaded files. Confirm each version with the deployment overview for your release, and monitor the RabbitMQ queue during a first full import to see whether the workers keep pace.
Platform and search sizing
The documented sizing gives the platform 2 cores and at least 8 GB RAM, and the Elasticsearch or OpenSearch node 2 cores, 8 GB RAM and 16 GB SSD. These figures are a starting point for planning. Final sizing depends on how much MITRE ATT&CK, CAPEC, CVE and KEV data you load, how long you keep it and how many analysts query it. Ask your architect to run a full import on representative hardware before you commit to a node count.
Worker-to-platform ratio
The deployment guidance recommends at least one platform node for every 3 workers. Workers consume RabbitMQ messages for asynchronous writes, so each added connector increases the write load the platform must serve. Recount workers whenever you add a connector or raise its schedule frequency, and add platform nodes when the ratio falls below the recommendation.
Outbound access to feed sources
The connectors fetch data from external sources, so the hosts that run them need outbound access to the MITRE ATT&CK, CAPEC, CVE and CISA KEV feeds, including any proxy your network requires. Test each source from the same host and network segment where the connector will run. Record the hostnames and ports in your firewall change request, and confirm them against the connector documentation for your release because source endpoints can change.
Connector token and LTS license key
Each connector authenticates to the platform with a token, so give each one a dedicated token and grant only the scope its documentation requires. Confirm that scope in the connector README before deployment. If your team runs an LTS line, the platform also needs the LTS license key for that line. After a one-month stabilization period, LTS releases receive only critical bug and security fixes, so plan upgrades around that schedule.
How connectors write reference data into the knowledge graph
Planning the MITRE ATT&CK and vulnerability connectors starts with understanding how they write data. OpenCTI structures its data with a knowledge schema based on the STIX2 standards and exposes that data through a web application and a GraphQL API. The objects a connector writes, such as attack patterns, weaknesses and vulnerabilities, are the nodes that reports, indicators and prioritization views later reference. If the reference layer is written inconsistently, every downstream link inherits the problem, so the write path deserves attention before the first load. The documented flow has four parts. A connector pulls source data from the upstream catalog or feed and maps each record to STIX2 objects. It then sends those objects as messages to RabbitMQ. Python workers consume the messages and carry out the asynchronous writes into the platform's data stores, after which the web application and GraphQL API show the results. Connectors for import, enrichment, file extraction, export and stream consumption all follow this pattern. Confirm in the connector documentation which queues each connector publishes to and how it schedules its pulls.
The components the team operates are RabbitMQ, the workers and the connector hosts. The documented dependency for RabbitMQ is version 3.11 or later, and the queue is the buffer between a connector and the graph, so its depth and health need monitoring during the first load. The deployment overview recommends at least one platform node for every 3 workers. Plan worker capacity against the volume of the ATT&CK, CAPEC, CVE and KEV loads, and confirm the sizing guidance for your data volume with the vendor documentation rather than assuming the minimum is enough. Before running any connector, confirm the minimum OpenCTI version it supports, the configuration keys it requires, and the authentication it uses to reach OpenCTI. Check also whether each connector runs as a full snapshot import or as incremental updates. Those answers decide how often the job runs, how much queue traffic it creates and how the team tests a rollback. Record the answers in the deployment runbook so the same settings can be reproduced on a rebuilt environment.
The main risks are duplicate objects, missing links and silent failures. Confirm how a re-run updates existing objects and whether it creates duplicates, and confirm how the connector handles records removed upstream. Confirm also whether a vulnerability connector can create references to weakness objects that do not exist yet, or whether the dependency must be loaded first. Illustrative example: if the KEV import runs before the CVE objects it references are present, the vulnerability records may load without their expected relationships, and the team will only notice when a prioritization view looks incomplete. Verification should happen in the web application and through the GraphQL API after each load. Check that queue depth returns to zero, that worker logs show no repeated write errors, and that a small sample of vulnerabilities links to the expected weakness and attack pattern objects. Repeat the same checks after the scheduled re-run, since the first load rarely shows the behavior that matters most over time.
Configure the MITRE ATT&CK connector first, then add vulnerability feeds
This sequence loads the MITRE ATT&CK reference layer into OpenCTI first, then adds CAPEC, CVE and the CISA KEV catalog one connector at a time. Each step ends with a check, so a faulty import is caught before the next source writes to the same knowledge graph. The result is a verified set of attack patterns and vulnerabilities that reports, indicators and prioritization can link to.
Confirm the OpenCTI version and release track
The platform owner records the running OpenCTI version and decides whether the team stays on the regular track or an LTS line. Regular releases use the x.YYMMDD.z pattern, while LTS releases add a -lts.n suffix and require a specific LTS license key. Confirm the image tag, the license key if applicable, and the versions of Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage against the deployment overview for that release. Done when the platform reports the expected version, and the worker logs show that workers are connected to RabbitMQ and idle without errors.
Deploy the ATT&CK connector with its token and URL
A platform administrator creates a dedicated connector user and API token with only the permissions the import needs. The team then sets the platform URL, the token, a connector ID and the connector scope in the connector configuration. Confirm the setting names in the README of the MITRE ATT&CK connector in the OpenCTI connectors repository for your release before you copy any older compose file. Start the container. Done when the connector appears as registered in the platform connector list and its status shows active, not in error.
Run the initial ATT&CK import
Trigger the first run using the connector schedule or the manual run option the connector documentation describes. Workers consume the import messages from RabbitMQ, so the first run is complete when the queue for the connector empties. Let this run finish before any other connector starts, so that a failure can be traced to one source. Done when the worker logs show a completed run for the ATT&CK connector with no repeated errors or retries.
Verify attack patterns in the user interface
An analyst opens the attack patterns view in the platform and searches for a known technique by its ATT&CK ID. For illustration, T1059 (Command and Scripting Interpreter) is a common check. Confirm the name, description, kill chain phases and tactic relationships match the MITRE ATT&CK release that was imported. Compare the total count of attack patterns with the count in the source release notes for that version. Done when the technique is found by ID, its kill chain phases are populated, and the counts agree.
Confirm the same objects through the GraphQL API
The analyst queries the GraphQL API with the connector or analyst token and requests attack patterns filtered by the ATT&CK external ID. The response should return the same technique, name and description that the user interface showed in the previous step. Run a count query and compare it with the user interface total. A mismatch usually means a permissions scope issue or an incomplete run, so check the worker logs before continuing. Done when the API returns the same technique by ID and the counts match the interface.
Add the CAPEC connector and verify its links
The team configures the CAPEC connector using the same token and URL pattern, then starts a single run. CAPEC entries add attack pattern context and link to ATT&CK techniques where the source provides a mapping. Once the run completes, check the worker logs for a finished import and open one CAPEC entry in the interface. Confirm that its relationships to ATT&CK techniques are visible. Done when the CAPEC run completes and at least one expected relationship resolves in the user interface.
Add the CVE connector and verify by identifier
Before the first CVE run, confirm that the Elasticsearch or OpenSearch cluster has enough disk and heap headroom for a large vulnerability import, and check the connector scope settings in its README. Start the connector and let it finish. Search for a CVE identifier you already know from your environment and confirm that its vulnerability object, description and publication data are present. Done when the logs show a completed run and the known CVE identifier is found by search and by GraphQL query.
Add the CISA KEV connector last
The CISA KEV connector marks vulnerabilities that CISA lists as known to be exploited. Run it after the CVE connector so that KEV entries attach to vulnerability objects that already exist, rather than creating duplicates. Check the worker logs for a completed run, then open a KEV-listed CVE and confirm that the exploitation flag or label appears on the vulnerability object. Compare the number of KEV entries in the platform with the catalog size in the source. Done when KEV entries resolve to existing CVE objects and the counts agree.
How ATT&CK, CAPEC, CVE and KEV data map to OpenCTI objects
This table shows how each MITRE ATT&CK, CAPEC, CVE and CISA KEV dataset is expected to land in OpenCTI, the object type it creates, the identifier used to match existing records, and what typically links to it. Treat it as a starting map: confirm each object type and identifier against the connector documentation for your installed version, and verify the mapping in a test instance before loading production data. The main takeaway is that the matching identifier decides whether imported data merges with existing objects or creates duplicates.
| Source dataset | OpenCTI object type | Matching identifier | What links to it |
|---|---|---|---|
| ATT&CK techniques and sub-techniques | Attack-Pattern | ATT&CK technique ID stored as an external reference | Reports, indicators, malware and intrusion sets |
| ATT&CK groups | Intrusion-Set | ATT&CK group ID stored as an external reference | Reports and campaigns, plus the techniques the group uses |
| ATT&CK software (malware and tools) | Malware or Tool | ATT&CK software ID stored as an external reference | Intrusion sets and the attack patterns they employ |
| CAPEC attack patterns | Attack-Pattern | CAPEC ID stored as an external reference | Related ATT&CK techniques where mappings exist, reports and indicators |
| CVE records | Vulnerability | CVE identifier used as the vulnerability name | Reports, indicators and attack patterns that exploit the weakness |
| CISA KEV catalog entries | Existing Vulnerability object updated | CVE identifier matched to an existing Vulnerability | Reports and prioritization views; confirm how known-exploited status is represented in your version |
| Analyst reports you author | Report | Report name and your own external reference | Attack patterns, vulnerabilities, intrusion sets and indicators cited in the report |
Which feeds to load first and how often to refresh them
Start by deciding which ATT&CK domains your team actually works in, then load only those. The MITRE ATT&CK connector can be configured for the domains it supports, so the first task is to confirm in the connector documentation for the OpenCTI version you plan to run which domains it ingests and how each one is selected. If your analysts work mainly with enterprise endpoint, identity and cloud techniques, loading mobile or industrial control content adds objects that no report, indicator or detection in your workflow will reference. Record the decision in writing, because every additional domain increases the number of objects that later reports and vulnerability links must be reconciled against.
CAPEC is worth loading only if analysts use attack pattern descriptions in their work, such as when writing intrusion summaries or explaining why a technique succeeds. Its value is narrower than ATT&CK's, so run a short pilot with a sample of recent analyst reports and check whether the CAPEC links add context they actually use. KEV usually works best as a prioritization input. It flags which CVEs are known to be exploited in the wild, and the team uses that flag to rank vulnerabilities already present in the graph. Importing the full KEV list as a catalog adds entries that have no connection to your assets, so confirm with your vulnerability management owner which subset matters before enabling a broad import.
Refresh scheduling is a team decision, and it should follow how often each source changes rather than a single fixed interval for everything. ATT&CK publishes versioned releases, so a monthly or quarterly review of new versions is usually enough to keep the reference layer aligned with your reports. CVE and KEV data change as vulnerabilities are published and cataloged, so those connectors need a more frequent run. Confirm the update pattern of each source with its publisher, then assign each connector a schedule and name the person who approves a version change. Write down who reviews a new ATT&CK release before it replaces the current one, since a silent version change can shift technique IDs that existing reports depend on.
After each refresh, run a short set of checks that show the reference layer stayed current. Confirm that the last successful run timestamp for each connector is recent and that the worker logs show no repeated errors. Verify that the ATT&CK version label in OpenCTI matches the release your team chose, and spot check several technique IDs and their relationships to the intrusion sets and tools your analysts use. Confirm that a KEV entry added since the previous run appears with its exploited flag set. Finally, check that the message queue has no growing backlog, since a stalled queue can look like a successful import while new data never reaches the graph. Keep the results with the change record so the next review starts from a known state.
Hardening connector credentials, feed trust and access
Connectors that load ATT&CK, CAPEC, CVE and KEV data hold a token with write access to your platform and reach out to public sources. The controls below limit what that token can do, where the connector can connect, and how imported data is labeled before other tools consume it.
Dedicated connector identity
Create a separate platform user for each connector and assign it only the permissions its import requires. Do not reuse an administrator or analyst account, because a leaked connector token would then carry those rights and its activity would blend into human activity. Before go-live, review the connector's user and confirm which capabilities your OpenCTI version needs for the connector to write its objects.
Token rotation and storage
Store each connector token in your secrets manager and inject it at runtime into the connector's environment. Set a rotation schedule your security team approves, and rotate immediately after a staff change or suspected exposure. Rotation is a sequence: issue the new token, update the connector, confirm imports resume, then revoke the old token. Check the connector documentation for the token settings each version accepts.
Restricted egress to feed sources
Connectors that load MITRE ATT&CK, CAPEC, CVE and CISA KEV pull from public sources over the internet. Allow outbound traffic from the connector host only to the source endpoints each connector documents, and deny everything else at the firewall or proxy. Recheck those hostnames after upgrades, since source locations can change. Log denied requests and alert on them, so a blocked feed appears in monitoring before anyone notices stale data.
TLP marking of imported data
Set a TLP marking on every object a connector imports so the marking travels with the data. Decide the marking for public reference data such as ATT&CK techniques and KEV entries on purpose, confirm each connector's default marking, and align both with your sharing policy. Markings matter downstream, because MISP exports, stream connectors and TLP filters read these labels. An unmarked or incorrectly marked object can reach an audience it was never meant for.
Enterprise Edition features and license
Several controls depend on the Enterprise Edition license. Audit logs and activity monitoring are Enterprise Edition features, and so is SSO configuration. Since 7.260224.0, defining and using authentication strategies is also an Enterprise Edition feature. Confirm your license covers each of these before you rely on them in the control design, and confirm the license terms with Filigran or your DeployOpen contact.
Verify access and imports
After each change, check that the connector's user holds only the expected permissions, that imports complete, and that object counts and source versions match what the feed published. Keep a short record of token rotations, egress rule changes and marking defaults so auditors and your own team can trace them. Repeat these checks after each OpenCTI upgrade, since connector behavior and permission requirements can change between releases.
Common connector failures, their causes and fixes
This table lists the failures most often seen when OpenCTI MITRE ATT&CK, CAPEC, CVE and CISA KEV connectors run, with the likely cause, the check that confirms it and the fix. Start with the check column to confirm the failure before changing configuration. Most failures trace back to connectivity, token rights, platform dependency versions, worker capacity or the LTS license key.
| Failure | Likely cause | Check that confirms it | Fix |
|---|---|---|---|
| Connector cannot reach the platform | Wrong platform URL or token, blocked network path or untrusted internal certificate | Connector container logs show connection refused, timeout or certificate errors | Confirm the URL is reachable from the connector host, trust the internal CA and correct the connector settings |
| RabbitMQ queues backing up | Too few Python workers for connector volume, or workers unable to consume messages | Queue depth rises in the RabbitMQ management view while worker logs show errors or idle consumers | Add workers within the documented ratio of at least one platform node per 3 workers, fix worker connectivity and confirm RabbitMQ is 3.11 or later |
| Search backend rejects writes | Elasticsearch or OpenSearch below the supported version, or nodes undersized for the data volume | Platform logs show indexing errors and the search cluster version or health does not meet requirements | Align to Elasticsearch 8.0 or OpenSearch 2.9 or later and the documented sizing of 2 cores, 8 GB RAM and 16 GB SSD per search node |
| Token scope errors | Connector token belongs to a user without rights to create or update the imported object types | Connector logs show 401 or 403 responses on write operations while reads succeed | Issue the token to a dedicated connector user with the capabilities it needs, then confirm the user's permissions in the platform |
| Duplicate objects after reruns | Rerun with changed configuration or state, so existing objects are not matched to the new import | Two objects share the same external reference name or identifier with different creation dates | Keep connector configuration and state stable between runs, merge duplicates in the platform and document the rerun procedure |
| LTS license key missing | LTS image deployed without the specific LTS license key for that line | Platform startup logs or the license status in the UI report that the license is missing or invalid | Obtain the LTS license key for your release line from Filigran, add it to the deployment configuration and restart the platform |
| Feeds load but reports do not link | ATT&CK or vulnerability objects imported but relationships to reports and indicators not created, or the reference import is incomplete | On a sample report, the knowledge graph shows no relationships to attack patterns or vulnerabilities | Confirm the reference connector completed a full run, re-run the affected import and check the connector's relationship settings |
What buyers ask before hiring help with the MITRE ATT&CK connector
How much does help with the MITRE ATT&CK connector cost?
Cost depends on the written scope, so no standard figure applies. DeployOpen does not publish a price list, and a quote follows from a written scope that names the feeds to load (MITRE ATT&CK, CAPEC, CVE and the CISA KEV catalog are the common set), the state of your existing OpenCTI platform and how much validation you want. Cost has two parts: the engineering work to plan, configure and test the connector, scoped as a fixed engagement, and any recurring support, upgrades or continuous testing you choose to retain. Ask the quote to separate these lines so you can see what is one-time and what recurs. Also ask who provides the infrastructure that hosts the workers and dependencies, because that capacity sits in your environment and its cost is yours to budget.
How long does it take to get the first MITRE ATT&CK import working?
The time to a first working import depends on how the platform is already built, and no fixed duration is given here. Timelines are set in the written scope, which is agreed before work starts. The main variables are whether OpenCTI is already running with healthy dependencies (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage), whether a test instance exists, how quickly your team approves access and how many feeds are in the first load. Extending a working instance usually moves faster than standing up a new platform. Ask for defined milestones: a test import, a validated import into the target instance and a handover of the configuration. Define the first import as a checkable outcome, such as the expected objects appearing in the web application and the GraphQL API.
What must our team provide before an OpenCTI connector project starts?
Your team must provide access, a named owner, feed decisions and a test instance before work starts. Infrastructure access: credentials or change approvals for the OpenCTI host, the dependency services and the network path the connector uses to reach its source. A named owner: one person who can approve scope changes and answer questions quickly. Feed decisions: which sources you want (MITRE ATT&CK, CAPEC, CVE, CISA KEV), how often each should refresh and how imported records should be labeled. A test instance: a non-production OpenCTI deployment where imports run and are checked before production. Without a test instance, validation usually moves onto production data, which raises risk. Confirm each item in the written scope so gaps are visible early.
Can our team load MITRE ATT&CK into OpenCTI without outside help?
A team with Linux, container and OpenCTI administration skills can do this alone. The deciding factors are capacity and risk. The connector work touches the platform, its worker processes, message queues and the feed sources, so every change needs a rollback path. Your team should confirm that it has people who can read the connector configuration, watch the worker logs and verify imported objects in the web application and GraphQL API. If that skill set exists and the team can take a test instance through validation, in-house delivery is a reasonable choice. If it does not, a partner can plan the work, write runbooks and leave your team able to operate the result. Compare the internal effort against a written scope, and include time for upgrades, which recur.
Which cost drivers change the price of a connector engagement?
The main cost drivers are the number of feeds, the state of the existing platform, the sizing of its dependencies and the scope of validation. More feeds mean more mapping, testing and monitoring. An existing instance with healthy search, cache, queue and object storage services is generally cheaper to extend than a platform that needs those services built or resized. OpenCTI's deployment overview documents starting sizing of 2 cores and at least 8 GB RAM for the platform, and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, and it recommends at least one platform node for every 3 workers. Confirm whether your current sizing meets that guidance before adding connectors. Validation scope matters too: checking one import differs from testing refresh cycles, failure recovery and the links into reports and indicators. Ask the quote to show each driver.
What work continues after the MITRE ATT&CK connector goes live?
Recurring work includes platform upgrades, connector updates, feed changes and monitoring. According to OpenCTI's product life cycle documentation, non-LTS releases ship from daily to weekly, and LTS releases arrive every 6 months, each supported for 1 year. Connector behavior may change with the platform version, so each upgrade needs a test against the connector. Feed changes, such as a source altering its format, field names or refresh schedule, also need review. Recurring support can be retained as a service that covers planned upgrades and checks, or your team can own it. LTS releases require a specific LTS license key and, after a one-month stabilization period, receive only critical bug and security fixes. Confirm which release line you run and who renews the key, then budget for these items when comparing options.
Which OpenCTI edition and version should we confirm before scoping the connector?
Confirm the edition and exact version before the connector is scoped. OpenCTI Community Edition is licensed under Apache 2.0, and Enterprise Edition is under a proprietary license, so the edition you run affects which features and support options are available. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature, so teams that need single sign-on for analysts should confirm their license early. Also confirm the release or LTS line, because the connector must match the platform version you run. Ask the partner to check the connector against that version in your test instance. If you are still evaluating, ask Filigran about trial licenses before committing to an edition.
How do vulnerability feeds like CVE and CISA KEV fit alongside ATT&CK?
ATT&CK, CAPEC, CVE and CISA KEV are separate feeds, so each needs its own mapping decision. Together they give reports and indicators a shared reference. ATT&CK provides technique and tactic structure, CAPEC describes attack patterns, CVE records individual vulnerabilities, and the CISA KEV catalog lists vulnerabilities with known exploitation. The engineering question is how entities from each feed relate in the knowledge graph and how often each feed refreshes. Load them in an order that lets relationships resolve, then test that a known technique, a known CVE and a KEV entry link to the same report or indicator. Ask the scope to name each included feed and how it will be validated. Adding feeds later is possible, but each addition brings its own mapping and testing work.
How DeployOpen works on this
DeployOpen plans, implements and supports self-hosted OpenCTI in your own infrastructure, including the connectors that load MITRE ATT&CK, CAPEC, CVE and CISA KEV data. Every engagement is fixed-scope, with the work agreed in writing before it starts. Scope, build, handover and support are written down so your team can review each step.
How we scope
- The written scope lists each reference source, such as MITRE ATT&CK, CAPEC, CVE and CISA KEV.
- It states the connectors to run, their schedules, and the data types each one writes into OpenCTI.
- Fixed-scope terms, deliverables and timelines are agreed in writing before any build work starts.
How we build
- Connectors are installed and configured against your OpenCTI version, with service accounts and secrets kept in your environment.
- Imports are tested for object mapping, duplicate handling and relationships to indicators, reports and vulnerabilities.
- Test results and every change to connector configuration are recorded in the project documentation.
How we hand over
- Handover covers runbooks for each connector, including start, stop, failure checks and how to re-run an import.
- Documentation describes the reference data model, source feeds, owners and the expected update cadence for each feed.
- Your team receives a walkthrough so administrators can review import status and investigate failed jobs.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Connector updates are reviewed against each OpenCTI release, including LTS lines and the upgrade path for your deployment.
- Feed changes, failed imports and drift in reference data are triaged against the runbooks agreed at handover.
