As the platform owner, your first job is to place KaizenFlow where it can read everything and break nothing. This module covers deployment topologies, network boundaries, and the non-negotiable rule that KaizenFlow sits beside the control path, never in it.
Beside the control path, never in it
KaizenFlow is an observability and analytics layer. It consumes a copy of plant data through read-oriented protocols (OPC-UA, MQTT, MTConnect) and reads from MES/SCADA/ERP systems. It does not write setpoints, issue commands to PLCs, or sit inline between a controller and a machine. The OEE tiles, downtime logs, and next-best-action rankings are all derived from telemetry that flows one way: out of the plant, into KaizenFlow.
This is the architectural commitment that lets a security review pass quickly. If KaizenFlow can never actuate equipment, an outage, a bad deploy, or a compromised account cannot stop a line. Design the data flow so that the worst failure mode is 'dashboards go stale,' not 'a press won't cycle.'
FIG. 1.ATWO PLACES TO FAILKF·CA-01
The same outage, bad deploy, or stolen account — with two different blast radii. Read-only beside the control path means the worst day is a visibility problem, never a production one.
Topologies and network boundaries
Most plants deploy a lightweight edge collector on the OT (operational technology) network that subscribes to the bus or polls an OPC-UA server, then forwards normalized data across a one-way or tightly-firewalled boundary to the KaizenFlow platform (cloud or on-prem IT zone). Model this on the Purdue/IEC 62443 zone-and-conduit pattern: the edge collector lives in a DMZ between OT and IT.
Edge collector: read-only subscriptions, buffers locally if the uplink drops
Conduit: a single, documented egress path (allowlisted destination, no inbound to OT)
Platform: ingestion, analytics, ledger, dashboards in the IT/cloud zone
Prefer data diodes or unidirectional gateways where the security policy demands it
FIG. 1.BZONE-AND-CONDUIT TOPOLOGYKF·CA-01
The Purdue/IEC 62443 pattern: the edge collector lives in a DMZ between OT and IT, reading one way out of the plant through a single documented conduit. Nothing above the line can reach a controller.
Key takeaway
KaizenFlow reads a copy of plant data from the OT side of a firewalled boundary; it never writes to controllers, so its worst failure mode is a stale dashboard, not a stopped line.
Module quiz · question 1 of 3
A controls engineer offers to give KaizenFlow write access to the SCADA server so the next-best-action engine can auto-acknowledge alarms and adjust thresholds. The security team is in the room, waiting for your answer.
Q1What do you say?
Module quiz · question 2 of 3
Q2Which deployment matches the IEC 62443 zone-and-conduit pattern this module builds on?
Module quiz · question 3 of 3
The uplink from your plant to the KaizenFlow platform drops at 14:00 and stays down for three hours.
Q3What happens on the floor?
Module 02 · 22 min · 2 fig.
Identity & access
Operations, engineering, and finance all live inside KaizenFlow but need very different access. This module covers wiring SSO and building least-privilege roles so the right people see the right tiles and the savings ledger stays trustworthy.
SSO as the single front door
Connect KaizenFlow to your identity provider (Okta, Entra ID, Google Workspace) over SAML or OIDC so authentication, MFA, and password policy live where you already manage them. Provision and deprovision through SCIM or group sync where available — when HR disables someone in the IdP, their KaizenFlow access should die with the same action.
Map IdP groups to KaizenFlow roles rather than assigning roles to individuals. A line operator who changes shift or a finance analyst who leaves a project should change access by changing group membership, not by an admin hand-editing a user.
FIG. 2.AACCESS FOLLOWS THE IDPKF·CA-02
When HR disables someone — or a shift change moves them — the group change in the IdP is the whole operation. KaizenFlow access dies or updates with the same action, no hand-edits.
Least-privilege roles across three audiences
Default every role to the minimum it needs and grant up, never down. The three core audiences map cleanly to distinct scopes:
Operations: view live line tiles, log reason codes for their line/area; no cross-plant or financial views
Engineering: full telemetry, failure forecasting, connector config for their assets; no ability to alter verified savings
Finance: the verified-savings ledger and savings methodology; read-only on raw OT telemetry
Admin (you): user/role and connector management — separated from the ability to silently edit ledger entries
FIG. 2.BLEAST-PRIVILEGE ROLE MAPKF·CA-02
Read the columns: no role holds both connector config and ledger entries. The people who configure the data sources can never adjust the verified savings those sources produce.
Worked example — building a least-privilege role
Maintenance asks for a new planner role: they schedule work orders from downtime history and failure forecasts on Plant 2. The tempting shortcut is cloning the Engineering role and deleting what looks unnecessary. Least privilege builds the other way — start from nothing and add only what the job needs.
start with no access
+ live line tiles Plant 2 only
+ downtime history read
+ failure forecasts Plant 2 assets
− connector config stays with eng/admin
− ledger entries never with data access
= maintenance-planner scoped · auditable
Note what never made the list: connector config and ledger entries. The planner doesn't need them, so the role can't leak them — and at the next access review, every grant maps to a task the job actually does. Map an IdP group to the role and let membership drive access from day one.
Key takeaway
Authenticate through your IdP with SSO and SCIM, then map groups to least-privilege roles so access changes when group membership changes — and no single role can both run the plant and rewrite the savings ledger.
Module quiz · question 1 of 3
During quarterly close, the CFO asks for one account that can both approve verified-savings ledger entries and edit connector configuration — 'so finance can move faster.'
Q1What do you set up?
Module quiz · question 2 of 3
Q2Why map IdP groups to KaizenFlow roles instead of assigning roles to individual users?
Module quiz · question 3 of 3
A new quality engineer needs failure forecasts for Line 3. The quickest fix is adding them to the existing Engineering group — full telemetry for every plant plus connector config.
Q3What do you grant?
Module 03 · 24 min · 2 fig.
Security posture
A security review will ask three things: is the data encrypted, is access logged, and can you prove it. This module covers protecting data in transit and at rest, audit logging, and the specific controls reviewers expect to see.
Encryption in transit and at rest
Every hop carries encryption. The edge collector's uplink to the platform uses TLS; OPC-UA sessions use their built-in signing-and-encryption security mode rather than 'None.' At rest, platform storage and the savings ledger are encrypted with managed keys, and where your policy requires it, you bring your own keys (BYOK/KMS) so you control rotation and revocation.
Don't forget secrets: connector credentials, IdP signing certs, and service tokens belong in a secrets manager, never in config files or shared with operators. Rotation should be a routine, scheduled task, not a fire drill after someone leaves.
FIG. 3.AEVERY HOP CARRIES ENCRYPTIONKF·CA-03
From the OPC-UA session to the ledger at rest, no hop rides in the clear — and the classic review finding is the first one: a session security mode left on 'None.'
Audit logging and the review checklist
KaizenFlow logs who did what and when — logins, role changes, connector edits, reason-code entries, and especially any change to a savings-ledger entry. These logs are append-only and exportable to your SIEM so they live independently of the platform.
When the review arrives, be ready to show the controls below mapped to your framework (SOC 2, ISO 27001, IEC 62443):
Encryption: TLS in transit, encryption at rest, key management/BYOK
Access: SSO + MFA, least-privilege RBAC, separation of duties
Logging: immutable audit trail, SIEM export, alerting on privilege changes
Boundary: read-only OT access, segmented network, documented egress
FIG. 3.BWHAT THE REVIEW WILL PULLKF·CA-03
Four control families, each mapped to your framework — SOC 2, ISO 27001, IEC 62443. Logging is where reviewers dig first: the append-only trail has to cover every ledger change.
Key takeaway
Encrypt every hop, keep secrets in a manager not a config file, and make the audit trail append-only and SIEM-exportable — especially for any change to a ledger entry, because that is what reviewers and auditors will pull.
Module quiz · question 1 of 3
A security reviewer finds OPC-UA sessions between the collector and a controller running in security mode 'None,' and connector passwords sitting in a plaintext config file on the collector.
Q1What's the remediation?
Module quiz · question 2 of 3
Q2What property must the audit log have before a SOC 2 or ISO 27001 reviewer will treat it as evidence?
Module quiz · question 3 of 3
Your security policy requires bring-your-own-keys for the platform's at-rest encryption, and the vendor supports BYOK through your KMS.
Q3What does holding your own keys actually buy you?
Module 04 · 22 min · 2 fig.
Data governance
The savings ledger is only valuable if it is auditable and compliant. This module covers data ownership, retention, residency, and lineage — the governance that lets finance and auditors trust every number.
FIG. 4.AGOVERN BY DATA CLASSKF·CA-04
Four questions, decided and documented before go-live, for every class of data the platform holds. Lineage is the one that makes the ledger defensible — it gets its own section below.
Ownership, retention, and residency
Decide and document, before go-live, who owns each data class: raw OT telemetry, reason-code annotations, model outputs, and verified-savings records. Ownership drives who can grant access and who signs off on deletion.
Set retention by class — high-frequency telemetry may roll up or expire after a defined window, while ledger entries and their supporting evidence are retained for the full audit horizon (often years). Residency matters when plants span jurisdictions: confirm where data is stored and processed, and pin region for deployments under GDPR or data-localization rules so telemetry from an EU plant doesn't silently land in another region.
Lineage keeps the ledger auditable
Every savings figure must trace back to its inputs. Lineage is the chain from a raw downtime or scrap event, through the reason code and the OEE/loss calculation, to the finance-verified ledger entry — with timestamps and the methodology version applied.
When an auditor asks 'where did this $ number come from,' you should be able to walk it backward to the exact events and the calculation that produced it. That means capturing the source connector, the raw event IDs, any human edits to reason codes, and which version of the savings methodology was in force at the time.
FIG. 4.BTHE LINEAGE CHAINKF·CA-04
When an auditor asks where a dollar came from, you walk this chain backward — to the raw event IDs, any human edits to the reason code, and the methodology version in force at the time.
Key takeaway
Govern data by class — ownership, retention, and residency set per class — and preserve end-to-end lineage so every ledger dollar can be walked back to the raw event and methodology version that produced it.
Module quiz · question 1 of 3
A new German plant comes online. The default deployment lands its telemetry in a US region. Legal raises GDPR; finance still wants the German savings in the global ledger.
Q1What do you do?
Module quiz · question 2 of 3
Q2What does lineage do for the savings ledger?
Module quiz · question 3 of 3
Storage costs are climbing, and an architect proposes one global retention setting: everything kept twelve months, everything older deleted.
Q3What breaks?
Module 05 · 20 min · 2 fig.
Operate & administer
A healthy deployment is one you can run for years without surprises. This module covers user lifecycle, monitoring, backups, and incident response — the day-two operations that keep KaizenFlow trusted.
User lifecycle and monitoring
Joiner-mover-leaver should be automatic: provisioning and deprovisioning flow from the IdP via SCIM/group sync, and you run a periodic access review to catch drift — stale admin rights, leftover contractor accounts, role creep. Tie every privileged change to the audit trail.
Monitor the deployment as two things: the platform's health and the data's health. Watch ingestion freshness and connector status (a silent dead connector means stale OEE tiles and missed savings), alert on edge-collector buffer growth or uplink loss, and alert on anomalous admin activity. Treat 'data stopped flowing' as a first-class incident, not a quiet gap.
FIG. 5.AA CONNECTOR DIES SILENTLYKF·CA-05
Ingestion doesn't fail loudly — it just stops, and frozen tiles look calm. A freshness alert turns the flat line into a page within minutes instead of a flawless-looking weekend.
Backups and incident response
Back up what is hard to recreate: the savings ledger, reason-code history, role/config, and connector definitions. Raw high-frequency telemetry may be reconstructable from source, but ledger and governance data must have tested, restorable backups — and you verify restores, not just that backups ran.
Define an incident runbook: detection, severity, who is paged, and rollback steps
Remember the boundary advantage: a platform incident degrades visibility, it cannot stop a line
For a suspected account compromise, disable in the IdP first (kills SSO sessions everywhere)
Capture lessons learned and feed them back into monitoring thresholds
FIG. 5.BTHE INCIDENT RUNBOOKKF·CA-05
Detection to containment to review, with the loop closed: lessons learned feed back into monitoring thresholds. For account compromise, containment lives in the IdP — one disable kills SSO sessions everywhere.
Key takeaway
Automate joiner-mover-leaver through the IdP, treat a dead connector as an incident, and keep tested restorable backups of the ledger and config — because a platform incident should only ever cost you visibility, never a running line.
Module quiz · question 1 of 3
2 a.m.: monitoring flags an admin account making rapid role changes and creating new users — far outside its normal pattern. You suspect compromise.
Q1First move?
Module quiz · question 2 of 3
Q2Which data must have tested, restorable backups?
Module quiz · question 3 of 3
Your nightly ledger backup job has reported green for a year. An auditor asks how you know a restore would actually work.
Q3The honest answer is —
Course complete.
You’ve worked all 5 modules. Sit the free practice exam to see if you’re ready for the real assessment — same format, instant grading, keyed back to the modules.