01
Create a read-only credential
Create the credential in Okta with the minimum read scope, paste it into devguard, and the connection is live. The integration page in the product spells out the exact permissions.
devguard reads your Okta org through the Management API and verifies the identity controls everything else depends on: an active MFA enrollment policy and a strong password policy.
4 read-only checks, run on a schedule. Each failure becomes a finding linked to a control — every check is listed, none are “coming soon”.
Connectivity check: fails if the API token cannot read the org settings or the org is not in the ACTIVE status.
org-reachable
Fails if the org has no active MFA enrollment policy, so members are not required to enroll a second factor.
mfa-enrollment-policy-active
Fails if the org has no active password policy that requires a minimum length of at least the configured threshold (default 12).
password-policy-strong
Fails if any active user has not signed in within the configured window (default 90 days). Also fails if no active users are returned, to avoid a vacuous pass. Users who have never signed in (no lastLogin) are not flagged.
no-stale-active-users
Bring your current platform's test list — we'll map it against these checks, gap by gap
Setup is minutes, not a migration project — and every step stays on your side
Create the credential in Okta with the minimum read scope, paste it into devguard, and the connection is live. The integration page in the product spells out the exact permissions.
The first run starts right after connecting, then repeats on a schedule. Results are timestamped, so your evidence has a history, not a snapshot.
Passing results attach as evidence to the controls they support; failures become findings you triage. When the audit comes, the proof is already connected.
Open any page for its full check register.
You create and scope every credential yourself, and you can revoke it at any time. Checks only read; results and evidence are stored in Switzerland and stay exportable.
Yes. The checks authenticate with a credential you create and scope yourself, and only ever read configuration. devguard holds no write access to Okta and remediates nothing silently.
A failed check becomes a finding linked to the control it supports, with the evidence attached. You decide the treatment — nothing pages your engineers and nothing is auto-remediated.
Checks run from Swiss infrastructure, and results and evidence are stored in Switzerland. Everything is exportable — your evidence stays yours.
A read-only API token from an administrator account with the Read-Only Administrator role is enough. devguard only calls read endpoints on the Management API.
20 minutes on how you run certification today. Bring your current test or control list and we'll map it against these checks — honestly, gap by gap.