The 2026 platform is built around point-in-time assessment: scan, score, prioritize, harden. The 2027 roadmap extends this into continuous verification -- tracking whether hardening changes hold after deployment, whether new API surface introduces new gaps, and whether the OPI score measured at assessment time is still accurate six months later. Point-in-time assessment answers whether you are protected today. Continuous verification answers whether you are still protected after your next deployment cycle.
Continuous Monitoring Track
The core addition in 2027 is a lightweight continuous monitoring mode that runs a subset of the full assessment -- surface discovery, rate limit probes against high-priority endpoints, and TLS configuration checks -- on a weekly cadence without requiring a full scan authorization. The design constraint is that monitoring probes must be indistinguishable from normal API traffic in terms of volume and pattern, so they do not trigger the customer's own alerting infrastructure. The output is a delta report: which findings are new since the last assessment, which previously-found gaps have been closed, and which hardening configurations have regressed. The goal is to close the gap between annual or quarterly assessments and the deployment velocity at which configurations actually change.
Why regressions are a first-class concern
WAF rate rules are overwritten during platform upgrades. TLS configurations revert to permissive defaults after certificate renewals. Authentication endpoint rate limits are disabled during load testing and never re-enabled. These regressions are common and go undetected in organizations that assess annually. Continuous verification detects them within days rather than months.
Protocol Coverage Expansion
The 2026 assessment covers HTTP/1.1, HTTP/2, TLS, and WebSocket. The 2027 roadmap adds gRPC and HTTP/3 (QUIC) as first-class assessment targets. gRPC is increasingly used for internal microservice communication that is exposed at the perimeter through gRPC-web gateways, and most WAF deployments have no specific rate limiting rules for gRPC traffic. HTTP/3's use of QUIC introduces new infrastructure gaps because many existing DDoS mitigation tools lack QUIC-aware inspection, and the UDP transport layer is handled differently by scrubbing infrastructure than TCP-based traffic. Both protocol additions will follow the same lab-to-scan pipeline as existing coverage: documented attack patterns first, safety-bounded probe implementation second, assessment module integration third.
Automated Hardening Verification
A recurring friction point in the current workflow is the verification step after remediation: the customer implements a rate limit or TLS configuration change and then needs to re-run a scan to confirm the fix is effective. In 2027, the platform will support targeted re-verification -- scanning a specific endpoint or configuration category after a reported finding is marked resolved, rather than requiring a full assessment re-run. This reduces the remediation cycle from days (wait for next assessment window) to hours (mark resolved, trigger targeted probe, confirm). The verification probe set is scoped to the specific finding type: if the finding is a missing rate limit on `/api/v1/login`, the verification probe confirms the rate limit is present and triggers at the documented threshold, not a full surface re-scan.
Integration and Workflow Expansion
The 2027 platform will add native integrations for the three most common security workflow tools used by assessment customers: a Jira ticket creation flow for each finding (with pre-populated remediation steps and evidence links), a Slack notification channel for OPI score changes above a configurable threshold, and a SIEM export format (JSON CEF) for organizations that want to incorporate DDactic findings into their security information management workflows. These are workflow integrations, not assessment capability changes, but they address the most frequently cited friction point in the post-assessment remediation phase: findings exist in the DDactic portal but the remediation work happens in Jira, and the gap between the two systems creates tracking overhead.
Research Pipeline to Assessment Coverage
The 2027 roadmap includes a formalized research track that will produce public findings from the DDactic lab infrastructure on an ongoing basis. The lab has already documented attack patterns for gRPC deserialization, HTTP/2 stream exhaustion, and WebSocket connection amplification that have not yet been translated into assessment modules. The 2027 research track will systematize this process: documented lab findings become published advisories, published advisories become assessment scan modules, and assessment modules become continuous monitoring probes. The goal is to close the gap between attack technique availability (attackers have access to these techniques now) and defensive measurement capability (most organizations cannot assess whether they are protected against them). Published findings are also how DDactic builds credibility in the security research community, which informs the quality of the research pipeline itself.
"An OPI score that is accurate at assessment time and wrong six months later is not useful for security planning. The 2027 architecture treats the assessment as the starting point of continuous measurement, not the ending point."
Start With a Baseline Assessment
The 2027 continuous monitoring capability starts from an accurate baseline. Run a full DDactic assessment now to establish your OPI score and priority findings before continuous tracking begins.
Run a Free Scan