Frequently asked questions

Lens is a read-only Chrome extension for the people who build flows: open a flow in the Okta Workflows designer and the cards with a finding are marked, with what is wrong and what it leads to. Assist sits beside the findings and helps fix them — a fix guide with examples from Okta’s own templates, a review of each change with sign-off by someone else, design help for a new flow, and plain-language explanations. Both come with a Workspace, run their checks on your Assay server, and never change anything in Okta. More about Lens.

No. The fix guide, change review, designs and explanations come from Assay’s own engine and pattern library. If you want written summaries and free-form answers, you can connect your organisation’s own model; it is sent card names and the question, never field values, credentials or table contents.

Each assessment carries a SHA-256 digest of the export that was read, a second digest over the conclusions that were drawn, and an Ed25519 signature over both together with the engine version and the timestamp. The signing key fingerprint is printed on the report.

The signature covers the conclusions rather than the PDF bytes, so re-rendering the document does not break it, but altering a finding, a control result or a score does. Verification runs on your machine against our published public key — you do not need to contact us, and we cannot change the answer after the fact.

If an engine has no signing key configured, its reports state that they are unsigned rather than implying otherwise.

No. You export a folder from the Workflows console and we analyse the file. There is no API token, no OAuth grant and no admin access at any point. Okta removes connection credentials during export. Anything typed directly into a card, such as a key pasted into a header field, stays in the file, which is exactly what Assay’s SEC-001 control looks for. If you ask us to connect to your tenant, we will decline.

Okta Workflows stores the body of a loop, and the contents of an error handler, as separate flow objects embedded inside the parent flow. They execute in production and can be edited, but they do not appear in the console flow list. Across 125 public Okta template folders, recursive analysis finds 867 flows where the declared list shows 560.

No, for four reasons. Terraform only reports drift on resources it manages — anything created in the console is invisible to it unless imported. The Okta Terraform provider does not model Workflows at all; it covers users, groups, applications and policies, so flows are outside its reach entirely. Even where it does have coverage, it compares attribute values on objects rather than what an automation actually does. And a terraform plan you ran yourself is not independent evidence — it is undated, unsigned and produced by the party being assessed. The two are complementary: teams already running Terraform tend to understand the gap fastest.

Two things. First, the architecture preview: pick an export and see your estate drawn in about a minute, with no account. Second, your grade: ask, and within one working day we send your A to E grade with the maintainability score and the sentence that explains it. The findings themselves, the control results and the signed report are part of a paid Assessment. Nothing you upload for the preview is kept.

Yes. The grade comes from the same engine and the same controls, which is why it can be trusted. What the free grade leaves out is the detail: which controls failed, which flows and cards are affected, and what to do about them.

The free grade tells you where the estate stands. A paid Assessment tells you why and what to do: every control result with its evidence, every finding with the flows it affects, a prioritised improvement register, and a signed report someone else can verify, including what could not be assessed from an export and why.

No. Assay is independent and has no commercial relationship with Okta. Okta and Okta Workflows are trademarks of Okta, Inc., used for identification only. That independence is the point — a platform vendor cannot credibly certify its own configuration.

No, deliberately. Scoring an estate and then selling the fix for it would compromise the independence the signed report rests on. We refer remediation to implementation partners and re-attest afterwards, so the improvement is measured by someone with no stake in the outcome. Where a referral fee applies, it is disclosed in the signed report.

Drawing your estate takes about a minute, and a free grade comes back within one working day. A paid Assessment is typically delivered within five working days of receiving the export, faster for smaller estates.

Files supplied for a paid engagement are held only as long as needed to produce and support the signed report, then deleted. What we retain afterwards is the derived record — control results, counts, scores, the file hash and the date — with folder and connection names redacted. This is set out in full in our privacy policy.

Ownership and dormancy. The format carries no owner field, no enabled-or-disabled marker and no last-run timestamp. We report those controls as not assessed rather than passed. Ownership can be assessed if you supply a register alongside the export.

Not yet. Today Assay assesses Okta Workflows. SailPoint, Saviynt and Microsoft Entra ID are next, then CyberArk, Oracle Identity and IBM Security Identity. None of them is available yet. If you need one, tell us: demand decides the order.

Yes. Enterprise plans include a self-hosted deployment inside your own network, so the export never leaves it. Ask us about it.

Yes — the file is sent to Assay, read, assessed, and then it is gone. It is not written to disk and it is not kept. What can be kept, only if you ask for it, is the derived record: each workflow's card graph, its findings, its grade and the dates each version was seen. Not the export, not connection secrets, not table contents. There is still no credential and no tenant access at any point, and a self-hosted deployment keeps the whole thing inside your own network.

Both, if you want it to. The assessment reads the export and needs nothing else. Separately, Assay can receive Okta's own execution log stream and correlate it against that assessment — so a finding that says an external call has no failure path can be set beside the fact that the call failed eleven times last month. Okta pushes to Assay; Assay never pulls, and still holds no Okta credential. One caveat we would rather state than have you discover: Okta's stream is flow-level, not card-level, so Assay names the flow, the run and the outcome, and the failing card where your tenant sends it. It is evidence of what happened, not live monitoring.

If you asked it to keep the assessment, yes. Assay records each workflow version keyed on the shape of its card graph, so it can show what a flow contained on a given date card by card, what changed between two versions, and which version a failed run was actually executing. It is off unless you turn it on, and deleting the org deletes every version held for it.

No. It is derived from the same export as everything else: the workflows something can start, the flows they call, the connections those use, the tables they read and write, and what the estate reaches outside itself, laid out in the order things run. Because it is read from the estate rather than drawn by hand it cannot be out of date. It also names the coupling nobody documents — two flows joined by a table, where neither calls the other and changing the columns one writes breaks the other in production.

Yes, and without asking us. The live demo is a workspace loaded with a sample Okta Workflows estate where every screen works: the findings, the flow map, the derived architecture, runtime views and version history. The address and passphrase are on the demo page. Uploads are refused on it, so nothing of yours is involved.

Your band is set when the Assessment or Workspace term starts and holds for that term. If the estate grows into a higher band, the new band applies at renewal, never mid-term.

Either a shared workspace passphrase, or your own Okta.

Connecting your Okta turns the shared passphrase into named sign-ins: people authenticate against your own identity provider, so multi-factor, password reset, lockout and de-provisioning are all handled where you already handle them, and removing one person's access does not mean changing a credential everyone else is using. Assay still holds no Okta API credential and reads no tenant — the OIDC client authenticates Assay to your Okta and does nothing else.

The passphrase stays as break-glass, deliberately. A deployment reachable only through the identity provider it exists to audit has a circular dependency you do not want at three in the morning.

No — export them all and they are assessed together as one estate.

A call from one folder into another then resolves, instead of being reported as a flow that goes nowhere. Subfolders are read as part of the folder that contains them, because the export records which folder contains which. The architecture diagram shows one folder at a time so it stays readable, and a flow in another folder that yours calls is still drawn, marked as outside it.

If you add a folder later, a new assessment can be added to the existing runtime baseline rather than replacing it, so the flows you were already watching keep correlating.