VERISCO Shield · IAM & Zero Trust Access

Enterprise identity for an application that already has users.

Add SSO, MFA, device posture, network policy and audit logging to a running application — without migrating a single account.

Request access How it works

verisco · shield / sign-in activity

Sign-in activity last 24h · 3 tenants

Evaluated1,284

Stepped up37

Blocked9

MFA cover94%

Time	Account	Origin	Device	Decision
09:52:11	n.haddad	DZ · Algiers	62	step_up
09:48:02	s.brahimi	DZ · Oran	91	allow
09:41:37	unknown	RU · datacentre	—	block
09:30:15	a.meziane	FR · Lyon	88	allow
09:22:49	k.saidi	DZ · Constantine	74	allow

Fig. 0.1 — The Shield console — sign-in activity with the decision trace for a step-up.

207 API endpoints

74 Automated test suites

14 Background jobs

24 Policy predicates

Counted from the repository, not quoted from a README.

The problem

Two bad options.

Adding SSO, MFA, brute-force protection, device checks and audit logging to an application that already has its own users normally means one of two things.

Rewrite the auth layer: Every route, every session assumption, every password-reset path. Months of work on code that already works, and a migration window you cannot roll back through.
Migrate every account: Export the user table into an identity provider and hope the password hashes survive the trip. If they do not, every one of your users is locked out at once.

Both are expensive, and both are irreversible.

The mechanism

Four steps, and the third one is a read.

Shield terminates the login at the edge, verifies against the store you already own, and hands your application a signed claim it checks locally with no round trip. Select a step to follow it through the diagram.

request path

Fig. 1 — A sign-in, end to end. Step 3 is the load-bearing one.

Take VERISCO away and the application still has all of its users.

Read-only is the default in code, not a configuration you have to remember, and an automated test fails the build if the write gate ever opens by default.

Capabilities

What the platform gives you.

Configured from a dashboard rather than written into your code.

Identity federation: MySQL user federation over bcrypt, or LDAP and Active Directory — both provisioned read-only. One isolated Keycloak realm per tenant, with per-tenant RS256 signing keys that rotate in three phases.
Six ways to prove it is you: TOTP, passkeys and WebAuthn, email OTP, SMS OTP, and one-time recovery codes behind an enrolment gate. Five CAPTCHA providers, including a self-hosted option for clients who will not call out.
Network policy: A pure, deterministic engine over thirteen signals — country, ASN, CIDR, impossible travel, VPN, proxy, Tor and threat feeds. Three outcomes: allow, step up, block.
Device posture: Eleven scoreable checks across five platforms — disk encryption, firewall, screen lock, TPM, endpoint protection and more — with attestation, so a claimed posture cannot simply be asserted.
Sessions that actually end: Revocation that cuts off the stateless gateway token, not just the identity provider. Open sessions are re-checked continuously as posture and network change underneath them.
Audit you can verify: A hash-chained audit log, exportable to CEF or RFC 5424 syslog, plus an offline verifier that imports nothing from the platform — so the other party can check the chain without trusting us.

Integration

Four ways to adopt it.

Pick the one that matches your stack. The analyzer can write most of this for you, but nothing here is hidden — this is the whole contract.

Any stack

A standard authorization-code flow against your tenant's realm. Nothing VERISCO-specific in your code — if your framework has an OIDC client, it works.

Choose this when you want no new dependency and are happy to handle sessions yourself.

discovery

GET https://auth.example.com/auth/realms/your-tenant/.well-known/openid-configuration

authorization_endpoint   …/protocol/openid-connect/auth
token_endpoint           …/protocol/openid-connect/token
jwks_uri                 …/protocol/openid-connect/certs

Node / Express

Caddy and the auth-injector do the whole OIDC exchange before the request reaches you. The middleware verifies the verisco_session cookie locally against your tenant's public key — zero network calls per request.

It accepts a set of public keys, which is what makes a signing-key rotation non-breaking.

app.js

const verisco = require('@verisco/verisco-middleware');

app.use(verisco({
  publicKeyFile: '/etc/verisco/tenant.pem',
}));

app.get('/me', (req, res) => {
  res.json(req.user);   // from the verified cookie
});

Node SDK

When you would rather drive the flow yourself than put a gateway in front of the app. The SDK wraps login, callback, session and route-guard helpers.

Both packages are served by the platform, not by npm — the install command your dashboard shows is the one that works.

app.js

const { VeriscoShield } = require('@verisco/verisco-shield');

const shield = new VeriscoShield({
  issuer:       process.env.VERISCO_ISSUER,
  clientId:     process.env.VERISCO_CLIENT_ID,
  clientSecret: process.env.VERISCO_CLIENT_SECRET,
  callbackUrl:  'https://app.example.com/oidc/callback',
});

app.get('/login',         shield.login());
app.get('/oidc/callback', shield.callback());
app.get('/account', shield.guard(), handler);

WordPress

A plugin, not a code change. It takes over determine_current_user, disables wp-login.php, rewrites the logout URL, turns off XML-RPC and guards the REST API.

It keeps a native admin-login bypass, so locking yourself out of your own site during setup is not a possibility.

requirements

VERISCO Security   v1.0.0
WordPress          >= 5.8
PHP                >= 7.4
Licence            GPLv2

Download it from your tenant dashboard.

Integration aid

The analyzer reads your project and writes the integration.

A CLI walks your codebase, builds an import graph, and identifies the authentication you already use — then produces an exact, reversible set of edits. Analysis runs against a local model first and only falls back to a cloud provider if the operator has enabled one. Your source is never written to disk or database on our side.

verify

$ npx @verisco/analyzer verify

  local   middleware mounted        ok
  local   public key reachable      ok
  local   routes protected          ok
  edge    gateway routing live      ok
  edge    old login sealed          FAIL

  11 of 12 · NOT READY

24 detectors: Eleven auth libraries, six frameworks, four role systems, three session strategies.
12 checks: Five local, six edge, one session. The badge cannot go green on local checks alone.
3 providers: A local model by default, a cloud provider only if enabled, and a template path that uses no model at all.
0 retention: No client source is written to disk or database on the server side, and a credential scan runs before anything is transmitted.

See Shield against your own application.

Tell us what you run — the framework, the user store, and roughly how many accounts — and we will tell you honestly whether Shield fits.

Request access About the team