See the weak spots in your Keycloak setup, ranked by risk

We examine how it is configured, how secure it is, how it performs and how it is run, then give you a short list of the issues that matter most.

Sound familiar?

Which of these sounds like your team?

Nobody can explain the config

Old realms and clients linger, and no one remembers why they were created.

Evidence for an upcoming review

A certification body or a large customer will want to know how sign-in and access are protected.

Slowing down as you grow

Every new batch of users makes the login screen a little slower.

Out-of-the-box security settings

Nobody has decided how long tokens should live or how many failed attempts should trigger a lockout.

Who are all these admins?

The list of people with admin rights keeps growing, and nobody checks it.

Missing patches

Your version predates several Keycloak security releases.

Process

How we work

  1. 01

    Agree the scope

    Together we pick the realms and clients to examine and the risks you care about most.

  2. 02

    Inspect

    We read through settings and logs, test performance and look at how the system is run day to day.

  3. 03

    Report

    A written report ranks each problem by how dangerous it is and flags the ones that are cheap to fix.

  4. 04

    Close the gaps

    Whoever you choose, your engineers or ours, works through the list in priority order.

Specifics

Technical details

  • For each realm, how long sessions and tokens last, which password rules apply, whether brute-force detection is on and what the master realm is used for
  • For each client, whether PKCE is enforced and how redirect URIs, mappers, scopes and secrets are set
  • Which login paths exist, including MFA, conditional steps and the way users recover an account
  • Who can administer Keycloak: admin roles, service accounts and whether the admin console is reachable from the internet
  • Every outside source Keycloak trusts, from other identity providers to LDAP directories and Active Directory
  • Whether you could recover from a failure: backups that restore, monitoring, clustering, event and admin logs, and how current your patches are
  • No one needs to visit or get write access: the audit runs remotely from a read-only account

Options

Flexible to fit you

  • Audit onceorCome back at intervals you set
  • You receive the report and act on itorWe also carry out the changes
  • Look at one area, security or performanceorCover security and performance together

Measurement

What we measure

  • High-risk issues still open, falling to none
  • Who holds admin rights, and how that list shrinks
  • How quickly Keycloak answers a sign-in request
  • The gap between your release and the latest security fix

FAQ

Questions we hear

Which parts of Keycloak does the audit touch?

Everything that decides who gets in and how: realm and client configuration, login flows, admin rights, links to directories and other identity providers, and day-to-day operations.

We already had a pen test. Why audit as well?

A penetration test hunts for a way in. Our audit asks whether Keycloak is set up and run the way it should be, by reading its configuration with read access.

Can we share the results with our auditors?

Yes. The report is written so a certification auditor or a customer's security team can follow it, and it records each fix once it is made.

Is there a set price for an audit?

Scope and complexity decide it, and both become clear in an initial call.

Let's find the gaps before someone else does