Is this the right starting point?

When to use it

Operators with security capability deployed and nobody with industrial context running it, or a team that needs augmenting to keep the plant running.

What you receive

Firewall and OT directory managed through your change control, monitoring that reaches a named person, and a monthly account of what is and is not covered.

What we start with

The security controls you already own, the coverage hours and escalation contacts you need, and the operating procedures the service has to respect.

Working within your operation. No production-impacting action is taken without the instruction of the person operations names. Operations decides.

Operators at a control room console with process displays and a plant overview screen

Cybersecurity is never a one-off project. It is a lifecycle, and it needs an independent, honest and skilled partner working with the operator through every stage.

  1. 01AssessGoSecure™
  2. 02RemediateAKTSecure™
  3. 03OperateInnovAKT Shield™
  4. 04LeadAKTElevate™

Then back to Assess, as the operation, the threat and the standards change.

Watch

The controls you own, run by people who have run plants.

What each service does week to week, and where the decision to act on the plant sits.

Operate00:22No sound

From the operator side

Engineers who have run the plants.

We are experts in the key cybersecurity and OT cybersecurity standards. Our team has more than 20 years of experience, with careers spanning automation and process control systems engineering and IT/OT cybersecurity. We have worked as operators with major global companies across oil and gas, power and utilities, chemicals, energy, manufacturing and petrochemicals, as well as in OEM leadership and consulting.

We know how the process runs, what a maintenance window costs, why a controller cannot simply be taken offline, and what a trip does to the unit downstream.

The service is led by people who have built and run OT managed security services, so detection is designed around your consequence model, not a generic enterprise baseline.

Service 01 · Firewall management

Keep firewall policy true to its purpose.

A firewall can be available while its policy has drifted away from the design. Rule base ownership across the IT/OT boundary and between industrial zones: each change reviewed against a documented policy intent, the justification recorded per rule, what is no longer needed retired, and naming kept readable for whoever inherits it. We propose and prepare; your process approves.

  1. Policy assurance

    Rule purpose, ownership, observed use, excessive scope, duplicates, shadowing, temporary access and recertification, with least privilege refined from operating evidence.

  2. Security-profile assurance

    Whether the intended inspection and filtering profiles are attached, current, tuned and working in the approved mode, with compatibility assessed before enforcement changes.

  3. Platform lifecycle

    Firmware, advisories, support status, security content, certificates, licenses and configuration backups, prioritized against exposure and operating constraints.

  4. Operational health and telemetry

    Availability, high availability, capacity, logs and configuration changes reviewed at the contracted cadence, with defined escalation.

  5. Controlled change

    Request, review, approval, implementation, rollback, verification and evidence for every material change, inside your change control and maintenance windows.

  6. A quiet rule is a question

    Low-use rules may carry failover, emergency operation, maintenance, seasonal production or disaster recovery. They are reviewed with the people who understand the operation, never deleted on an assumption.

Five gates from request to closure.

  1. Request and review

    Purpose, owner, affected boundary, technical requirement and the proposed change.

  2. Risk and approval

    Security benefit, dependencies, compatibility, process risk and the named approval required.

  3. Pre-change protection

    Health, backup, rollback readiness and the operating go or no-go confirmed.

  4. Controlled implementation

    The approved change made while the service and the operation are watched, and reversed against agreed criteria.

  5. Verify and close

    Technical, security and operational results confirmed, with the new configuration and evidence preserved.

The firewall cannot see a path that never crosses it: a physical bridge, a dual-homed system, a wireless link or removable media. Where that matters, we add path and segmentation validation through ControlPulse™.

Service 02 · OT Active Directory

Protect the identity services the plant depends on.

The OT domain is frequently the most consequential and least maintained system on a plant network. Directory, authentication, name resolution and Group Policy affect the engineering systems and applications the operation relies on, so their security is managed together with their operating dependencies.

  1. Directory health and continuity

    Domain controller services, replication, directory DNS, time synchronization and capacity: the dependencies behind reliable authentication.

  2. Account and privilege lifecycle

    Joiner, mover and leaver actions, stale accounts, privileged groups, delegated access and recertification, reviewed with the responsible owners.

  3. Service-account dependencies

    The purpose, owner, privilege and dependent application behind every non-human identity, including the ones a historian or HMI needed years ago. Changed in coordination, never rotated blindly.

  4. Group Policy and hardening

    Purpose, links, delegation, effective settings, compatibility and backup of each policy, with changes staged around the systems that inherit them.

  5. Authentication, trusts and paths

    Protocols, delegation, trusts and administrative paths, including the trust with the enterprise domain, where much IT/OT exposure actually lives. Separate trust systems stay separate until the design says otherwise.

  6. Recovery preparation

    Backups, protected credentials, restoration order and dependencies such as DNS and virtualization. A successful backup job is not a demonstration of forest recovery.

A compatibility gate before any security setting changes.

  1. Identify what depends on it

    Applications, service accounts, authentication, DNS, time, policies and vendor-supported configurations.

  2. Review and prepare

    Design, security impact, peer review, representative testing where available, backup and rollback.

  3. Authorize and implement

    Maintenance and operational approval, redundant components sequenced, defined indicators watched.

  4. Verify and document

    Directory health, effective policy, authentication and the affected OT functions confirmed; evidence and exceptions kept.

Service 03 · Expert-led OT monitoring

Understand the event before choosing the action.

Security control effectiveness monitoring, reporting and improvement. Detection is designed from your operational consequence model: which functions must keep running, what normal traffic looks like between zones, which engineering actions are expected and which are not. A configuration download to a controller outside a maintenance window means something specific in a plant; in an enterprise baseline it means nothing at all.

Controls also degrade quietly: a sensor stops receiving after a switch replacement, a log source drops out, an allow-list drifts after a vendor visit. Shield tracks whether each control in scope is still doing what it was installed to do and reports the gap the week it opens. Collection uses OT-native sensors and log sources built for production networks.

  1. Source and coverage baseline

    In-scope logs, events, sensors and asset context, with the important gaps recorded rather than assumed away by a green dashboard.

  2. Process-aware review

    Scheduled maintenance, approved access and engineering activity told apart from abnormal behavior, using the operating context.

  3. Detection and escalation path

    Logic, alert routing and ownership reviewed, because an alert in a queue is not a person receiving it and acting on it.

  4. Control-health observations

    Collection gaps, configuration drift, changing rules and account conditions: the evidence that protection is degrading.

  5. Investigation within scope

    The available evidence examined and context preserved, with a plain statement of what can and cannot be concluded.

  6. Tuning and improvement

    An owned backlog for sources, logic, escalation and architecture, tuned on a standing cadence as the plant changes.

Three questions kept separate.

Is the source healthy? Did something relevant happen? Does the control achieve its purpose? Collection health, observed events and verified effectiveness are different levels of assurance. When a control-effectiveness claim needs formal verification, that is a ControlPulse™ engagement.

  • Escalation and incident coordination with decision rights agreed and tested before they are needed.
  • Coverage stated as what is monitored and, explicitly, what is not, so blind spots can be funded and closed.
  • Detection tuned after turnarounds, new lines and migrations, because each one invalidates a baseline.

An alert nobody is authorized to act on is a record, not a defense.

Authority boundary

Where the decision sits.

The security operations center never acts on the plant on its own authority. It establishes what is happening and what it means for the process. The decision to act belongs to the people accountable for the plant.

  1. Detection

    Platform and sensors

    What happens here

    OT-native sensors and log sources raise a candidate event. Nothing acts on it automatically: any automated response on a production network is designed, tested and approved with operations first.

    What does not happen here

    Nothing acts automatically: no containment, blocking or account disable at this stage.

  2. Triage

    SOC analyst

    What happens here

    Is it real, is it novel, and what asset is it on. Enriched against the asset inventory, current change records and open maintenance windows before it goes anywhere.

    What does not happen here

    No contact with the plant floor yet, and no ticket raised against operations.

  3. Industrial context

    OT analyst

    What happens here

    What does this asset do in the process, what is the unit doing right now, is there an outage running, is a vendor on site. This is the step a generic SOC cannot perform, and it is where most false positives end.

    What does not happen here

    No recommendation to stop, isolate or restart anything.

  4. Site decision

    Operations and plant owner

    What happens here

    Whether to act on the process, and when. Taken by the person accountable for the plant, with the analyst on the call supplying what is known and what is not.

    What does not happen here

    The SOC advises. It does not decide, and it does not escalate over the site.

  5. Action and record

    Joint, under site change control

    What happens here

    Containment executed on the site's instruction by whoever holds change authority for that system, which can be our engineers where the service definition gives them firewall or OT directory access, through the site's emergency or standard change process. Written up, and fed back into detection so the next one is caught earlier.

    What does not happen here

    Nothing is executed without the site’s instruction, and nothing is executed on controllers or safety systems.

The escalation path an alarm actually travels. Select a stage to see who acts, and what they are not permitted to do.

Coverage models

Two coverage models. The same three services in both.

Neither model is the better product and neither is a stepping stone to the other. Whether you run an in-house OT SOC, buy OT managed security services, or feed industrial context into an existing IT SOC, the question is the same: how quickly the loss or manipulation of a critical function becomes an operational or safety event, and who is available to decide when it does.

8×5

What it covers

  • Analyst attention during your working day, in your site's time zone, on the working days agreed in the service definition.
  • Firewall management, OT Active Directory management and expert-led monitoring, all three delivered in full.
  • Detection continues to run and events continue to be collected outside those hours. What pauses is the analyst reviewing and escalating them, not the collection.
  • Queued events are triaged at the start of the next covered period, with severity ordering applied so the oldest is not automatically the first.

Who it suits

The gap is real and we state it in the service definition rather than in a footnote: an event beginning on a Friday evening may not be reviewed by an analyst until Monday morning. Whether that is acceptable is a consequence judgment your operations leadership makes, not a judgment we make for you.

  • Operations where the loss of a critical function takes hours rather than minutes to become a safety or production event, and where a process upset would be noticed by shift staff long before a security analyst saw it.
  • Sites that do not run continuously, or that run unattended overnight with limited change activity.
  • Organizations with no one available to receive a call at three in the morning. Round-the-clock detection escalating to a phone nobody answers buys the appearance of coverage rather than coverage.
  • Estates where the honest first priority is monitoring quality and blind-spot closure during working hours, before extending the clock.

24/7

What it covers

  • Analyst attention at every hour, including nights, weekends, public holidays and the periods when industrial estates are least staffed and most changed.
  • The same three services as 8×5. Nothing is withheld from the lower model and nothing additional is unlocked by the higher one.
  • Escalation against the agreed matrix at any hour, which only produces value where your side of that matrix is also staffed at any hour.
  • Turnaround and shutdown periods covered as they run, when vendor access, temporary connections and out-of-hours engineering activity are all at their peak.

Who it suits

What 24/7 does not change: containment authority still sits with operations, no analyst makes a production decision at any hour, collection stays on OT-native tools built for the production network, safety systems remain out of scope, and firewall and directory changes still run through your change control and your maintenance windows. A faster clock does not create authority that the service was never designed to hold.

  • Continuous processes where minutes matter: operations in which loss or manipulation of a function moves toward a safety, environmental or major production consequence faster than a working-hours review cycle can respond.
  • Organizations with their own people on shift who can receive a call and act on it, because escalation is only as fast as the slowest link in it.
  • Regulated entities whose obligations require demonstrable detection and response capability outside working hours.
  • Multi-site estates spanning time zones, where any single working day leaves another region uncovered.

Coverage and authority

You choose the coverage. Operations keeps the authority.

Both coverage models are genuinely available and both are properly staffed. Which one is right is a consequence question, not a commercial one.

  • 8×5 or 24/7

    Agreed in the service definition, not sold as an upgrade path.

  • The deciding factor is consequence

    How quickly loss or manipulation of a function becomes an operational or safety event, and whether your own people are on shift to receive a call.

  • Containment authority stays with you

    Options are presented with operational impact attached; no analyst makes a production decision.

  • OT-native collection

    Sensors and collectors built for production networks, connected through your change control.

  • Safety systems out of scope

    SIS is not monitored as a cybersecurity testbed.

  • Changes run through your change control

    Firewall and directory work inside your windows and vendor agreements.

Fit

Where InnovAKT Shield™ fits, and where to start instead.

Use InnovAKT Shield™ when

  • You have bought OT security tools and nobody is running them week to week.
  • You have monitoring capability deployed but nobody with industrial context watching it.
  • Your IT SOC receives OT alerts it cannot interpret, and escalates either everything or nothing.
  • Firewall rules and OT domain accounts have drifted, and no one owns the policy intent.
  • You need continuous assurance that controls still work, not a point-in-time statement each year.
  • Your team can cover working hours but not nights, weekends, turnarounds or holidays.
  • A regulator, insurer or customer expects demonstrable detection and escalation capability.

Start with another service when

  • You have no asset or architecture visibility yet. Start with GoSecure™, so monitoring is built on a mapped environment.
  • A foundational gap needs project work first, such as a boundary firewall, a directory rebuild or a segmentation change. We deliver it through AKTSecure™, and Shield then operates the result.
  • You need forensic investigation, threat hunting or on-site incident support. We scope it as a dedicated engagement alongside the service — talk to us.
  • Nobody internally owns OT security decisions yet. AKTElevate™ establishes the owner and the decision rights that Shield escalates to.

Framework alignment

Detection designed in one language. Reported in another.

The service is structured around ISA/IEC 62443 — zones, conduits and the capability requirements your engineering teams and industrial vendors already work to. That is what makes a detection explicable to the people who have to act on it.

Detection logic is designed and documented against MITRE ATT&CK for ICS, so coverage can be discussed as specific adversary techniques against specific industrial functions rather than as a product feature list. Reporting is structured to NIST CSF 2.0 where leadership already reports in that language.

NERC CIP evidence requirements are built into the reporting only where you are a registered entity. Mapping is scoped to what actually governs you — adding frameworks that do not apply produces pages, not assurance.

NIST SP 800-82 Rev. 3 frames the three services: firewalls and network security (Appendix E.1.1 and §5.2.3) and maintenance of controls (§6.2.5) for firewall management; identity management and access control (§6.2.1) for the OT domain; network monitoring (Appendix E.2) with detect and respond (§6.3, §6.4) for monitoring. Its comparison of OT and IT security (§2.4) is why operations keeps the authority. We describe our work as aligned with it.

Outcomes

What is different in the operation afterwards.

Alerts that reach the right person

Escalation paths and decision rights are agreed in advance and exercised. During contracted analyst coverage hours, actionable detections are escalated to the nominated responders. Outside those hours, collection, review and escalation follow the coverage model and procedures defined in your service agreement.

Control drift caught in weeks, not years

A failed log source, an orphaned firewall exception or a stale privileged account surfaces as a reported gap with its operational consequence, instead of appearing in the next audit.

Coverage you can state accurately

A written, current picture of what is monitored and what is not. Being able to name your blind spots is what allows them to be funded and closed.

A team that keeps its own capability

Your people stay in the escalation path and in the service reviews, so knowledge of the environment accumulates inside your organization rather than only inside ours.

Deliverables

What you receive, in writing.

Exact contents and cadence are agreed in the service definition. These four are present in every Shield service.

  1. Service definition and escalation matrix

    Coverage model, monitored scope, data sources, severity definitions, contact tree with named roles, response times per severity, and the explicit statement of which decisions belong to whom during an incident. Signed by both sides before go-live.

  2. Monthly service report

    Events detected and their disposition; what was escalated, to whom, how quickly, and what the outcome was; which events turned out to be operational rather than adversarial and what that revealed; control effectiveness status with any gap opened or closed; firewall changes reviewed, implemented and rejected; privileged and service account changes in the OT domain; open items with owners and dates.

  3. Detection coverage and blind-spot register

    Monitored zones, conduits and sources mapped to ATT&CK for ICS techniques, alongside the named list of what is not covered, why, and what closing each gap would require. Updated as the environment changes.

  4. Quarterly service review

    A working session rather than a document: tuning decisions and their effect, escalation performance against the agreed matrix, changes in the plant that alter the baseline, recommended adjustments to scope or coverage, and the decisions needed from you.

Engagement process

Five steps from definition to steady state.

Onboarding duration depends on site count, data source availability and change-control cadence. It is established during service definition, before any commitment is made.

  1. Service definition and coverage selection

    Scope, sites, systems and data sources agreed in writing. Coverage set at 8×5 or 24/7 based on how quickly a loss of function becomes an operational or safety consequence and on whether your own people are available to receive a call outside working hours. Severity definitions, escalation matrix, decision rights and exclusions documented and signed.

  2. Onboarding and connection

    OT-native collection established on the production network, log and event sources connected, firewall and directory administrative access agreed under your access governance, and the environment documented as found. Conducted inside your change control and maintenance windows, with vendor agreements checked before anything is connected.

  3. Baselining

    Normal operating behavior observed and characterized with your engineering team: expected traffic between zones, routine engineering activity, maintenance patterns and vendor access windows. Firewall policy intent and the OT domain account and group policy position documented as a baseline that future drift can be measured against.

  4. Go-live under agreed escalation

    The service begins at the agreed coverage, with a defined stabilization period in which detection thresholds are tuned against real operating conditions and the escalation path is exercised deliberately rather than discovered during an incident.

  5. Continuous improvement

    Standing tuning cadence, blind-spot register maintained as the plant changes, control effectiveness tracked between assessments, and quarterly review with your team to adjust scope, coverage and priorities. Turnarounds, migrations and new lines are treated as baseline events, because they are.

Questions we are actually asked

What operations asks before an outside service sees the network.

Will you ever take an action on our network?

Yes, on operations' instruction. When something is detected you receive the observation, the operational function affected, the credible interpretations including the ones that turn out to be a maintenance activity, and the containment options with the production consequence of each attached. Operations decides, and where the service definition covers it, our engineers carry out the chosen option through your emergency or standard change route.

Firewall and OT directory changes are raised, reviewed and implemented inside your change control and your maintenance windows. We propose, prepare and, where you ask us to, implement; your process approves. A service that isolates a segment at three in the morning on its own authority is not a mature service, whatever its response time looks like.

We already have an IT SOC. Why would we pay for a second one?

Usually you would not be buying a second one. The common position is an IT SOC receiving OT telemetry it cannot interpret, so it either escalates everything and is ignored, or filters heavily and misses the events that matter. Shield can run as the industrial context layer feeding your existing SOC rather than as a parallel service, which is the usual answer to the in-house OT SOC versus managed security services question.

If your SOC already has engineers with process knowledge, a detection set built from your consequence model, and an escalation path that operations has agreed, then what you need is tuning and a blind-spot review rather than a full managed service, and we deliver that as a focused engagement.

What exactly are you collecting, and does our process data leave the site?

Data scope is settled in the service definition before go-live: which sources are collected, what is retained, how long, where it is stored, who within our team can see it, and what happens to it when the service ends. Collection uses OT-native sensors and connectors built for production networks, deployed through your change control.

Where residency or contractual restrictions mean data cannot leave the site or the country, the collection and analysis tier can sit locally with only the working views leaving. That changes the commercial model and the onboarding effort. It does not change the capability, and we would rather adjust the architecture than ask you to relax a restriction you are right to hold.

What happens if you miss something?

Two different situations, and we separate them deliberately. If the event occurred in a segment, link or system on the blind-spot register, the coverage limit was declared in writing before go-live and reported every month since. That is a funding decision that was left open, not a detection failure, and pretending otherwise would make the register worthless.

If it occurred in a monitored path, it is a failure of our detection logic or our triage. It goes into the service review with the reasoning, the logic is changed, and the change is recorded. No monitoring service detects everything, and any provider claiming complete visibility of an industrial estate is describing a sales position rather than an engineering one.

Do we have to buy a platform from you?

No. We hold no resale margin and no referral position in any product. Shield frequently runs on capability you already own and have not fully configured, which is a cheaper and faster starting point than replacing it.

Where a genuine gap exists, the requirement is written so you can tender it competitively. You keep the license relationship, which also means you keep the ability to change service provider without changing your platform.

Our own team will read this as being replaced.

It is a fair concern and it is worth addressing directly with them rather than around them. Your people stay in the escalation path, sit in the quarterly service reviews, and hold the operational knowledge the detection logic is built from. A baseline for your plant is tuned with your engineers, not around them.

There is a version of this service that keeps the customer out of the loop and reports monthly. It is easier to run and it leaves the organization weaker each year, because the knowledge of the environment accumulates in the supplier. Where you do not yet have people to involve, we build that capability with you through the InnovAKT Academy, so the knowledge of your environment stays in your organization.

Next step

Start with the coverage conversation, not the platform.

Before scope or tooling, the useful question is how long your operation can tolerate the loss of a critical function, and who is available to decide when it happens. That answer sets the coverage model, and most of the rest follows from it.

  • Coverage agreed, not upsold — 8×5 or 24/7, chosen on consequence
  • Three services, fully delivered — firewall management, OT Active Directory, expert-led monitoring
  • Production authority stays with you — every containment option carries its operational impact
  • Vendor-independent — we resell no products and take no referral fees

Questions buyers ask

What we are asked before we start.

What is InnovAKT Shield™?

InnovAKT Shield™ provides managed OT security across the capabilities and coverage hours agreed with your organization. It is three services that can be taken together or separately: firewall management, OT Active Directory management, and expert-led monitoring of control effectiveness. Decisions affecting production remain with the authorized operating team.

Who is InnovAKT Shield™ designed for?

Shield is for operators that need ongoing management of agreed OT security capabilities, either alongside their existing team or feeding industrial context into an existing SOC. Scoping establishes the sites, systems, data sources, coverage hours, escalation paths, and responsibilities before service begins.

Are assessment, architecture, and implementation included?

They can be. Assessment runs through GoSecure™, and design and implementation through AKTSecure™, and either can be included in the Shield agreement or scoped alongside it. Shield’s recurring service is defined by its agreed capabilities, coverage and responsibilities, and any foundational project work is stated before the managed service begins.

What does Shield's firewall management include?

Rule base ownership across the IT/OT boundary and between industrial zones: each change reviewed against documented policy intent, justification recorded per rule, unowned and expired rules retired, and naming kept readable. Every change is raised, reviewed and implemented inside your change control and maintenance windows. We propose and prepare; your process approves.

What does OT Active Directory management cover?

Directory health and continuity, account and privilege lifecycle, service-account dependencies, Group Policy and hardening, authentication and trusts including the trust with the enterprise domain, and recovery preparation. Every security setting passes a compatibility gate and runs through your change control.

What does expert-led OT monitoring cover?

Monitoring of security control effectiveness with industrial context: a source and coverage baseline, process-aware review, detection and escalation to a named person, control-health observations, investigation within scope, and a standing tuning backlog. Collection uses OT-native tools built for production networks, blind spots are stated in writing, and production decisions stay with operations.