It accumulates
Granted, never revisited
Every shortcut taken for speed stays in place until someone removes it. Almost no one does.
Why WebFrolic / Identity debt
Identity debt: the access that piles up, and never gets cleaned up.
Presenters at identity conferences keep naming the same quiet failures: orphaned service accounts, stale test users, permissions no one revisits, keys that never rotate, all-or-nothing delegation, and privileges buried in groups. None is a dramatic exploit. All of them accumulate. WebFrolic is built — type by type and setting by setting — so this debt can’t pile up.
Six risks. One identity provider that is built to prevent them.
The pattern
The access that accumulates is the access that gets exploited.
Most identity risk isn’t a break-in. It is the residue of everyday work — and it shares three traits.
It hides
No single view
Access spreads across groups, keys and shared accounts, with no one able to see the whole picture at once.
It’s unaccounted
No owner, no trail
Shared and orphaned credentials mean an action often can’t be tied back to a person.
Accounts
Orphaned service accounts
Service accounts often run on shared credentials that no person owns. They get orphaned, keep working, and because many systems let them be signed into or impersonated, their actions can’t be tied to anyone. Vast numbers sit unaccounted across the industry — a prime threat vector.
How WebFrolic does it ↗How WebFrolic fixes it
- Explicit user types: Regular, Service, Machine, System and Test.
- Service, Machine and System users hold no credentials and cannot be impersonated or signed into directly.
- A person assumes a service user to act — one assumption at a time, and every assumption is audited.
- Admins can require approved networks and an authenticator assurance level before one can be assumed.
- That turns a service account into safe break-glass, gated behind an access-request workflow.
- System users own background and system operations, so every system-level change is attributable.
Accounts
Test users in production
More teams test in the production environment itself, creating test users that go stale, lose an owner, and become an abuse vector hiding among real accounts.
How WebFrolic does it ↗How WebFrolic fixes it
- Test user is a first-class type, kept distinct from real users.
- Lifecycle rules, so test accounts expire instead of lingering.
- Assigned email domains keep them contained and easy to identify.
- OTP-based authentication for the email and phone numbers configured for testing.
Access
Permissions no one revisits
To get things done, privileges are granted quickly with the intention of applying least privilege later. Later rarely comes, so accounts quietly accumulate rights and become high-value targets.
How WebFrolic does it ↗How WebFrolic fixes it
- An expiry can be set on every access role assignment.
- And on every resource association — group membership, secret access.
- Temporary access stays temporary: it lapses unless it is renewed.
- The onus to justify continued access moves to the person who needs it, not to a review no one runs.
Keys
Keys that never expire
Most systems can’t rotate keys or cap their lifetime, so API keys and signing certificates live for years — long after anyone remembers why.
How WebFrolic does it ↗How WebFrolic fixes it
- Key expiration is mandatory: one year maximum for regular keys, three years for SAML certificates, by default.
- Rotate without an outage: revoke an old key immediately, or give it a 12-hour grace window.
- SAML uses primary and secondary certificates; the secondary is accepted if the primary doesn’t match the signature.
- So certificate rotation happens with no downtime.
Access
All-or-nothing delegation
When a system can’t delegate narrowly, people share whatever they have — a key or an access token that carries full privileges — just to let a teammate or a script do one thing.
How WebFrolic does it ↗How WebFrolic fixes it
- Granular permissions on every resource: authenticators, applications, groups, secrets.
- Fine-grained access that is real, not a claim: admins configure exactly which permissions on a resource are available to API access.
- API keys are scoped to those permissions, so you delegate one capability, not an account.
Model
Privileges buried in groups
Hanging privileges off nested groups, with roles granted at the group level and no resource scope, creates a forest of inherited rights with several possible calculation paths. The full picture is hidden from human review — usually a re-implementation of Active Directory’s group-based privileges.
How WebFrolic does it ↗How WebFrolic fixes it
- A role is never a blanket grant on a group — it is always assigned for a specific resource instance, to a user or to a group.
- A group can hold several roles on one resource instance, or different roles on different resource instances.
- Only users are members of a group — there are no nested groups to trace through.
- Automation can bridge the two: a rule that runs when someone joins or leaves a group can assign them a role as an explicit step.
- Because every grant names its resource instance and membership stays flat, who-can-do-what stays computable and visible, instead of hiding in inherited group privileges.
Related
How WebFrolic keeps access accountable.
The capabilities behind each answer above.
Find your identity debt
Start with the access no one owns.
Bring the accounts, keys and permissions you can’t fully explain. A walkthrough can show how WebFrolic would prevent them from piling up — and our team can help assess what you already run.