🚨 OasisPro · Emergency Access · PermissionWorks
Granted at 2am. Still active three weeks later.
IFS Cloud emergency access granted during an incident is some of the highest-risk access in your entire environment, precisely because it's granted fast, under pressure, by people whose focus is fixing the problem, not thinking about access hygiene. Nobody's watching the clock on it once the crisis passes.
That's the pattern behind almost every emergency access control finding: broad access granted correctly, for a real reason, at 2am, that nobody circled back to remove once the emergency actually ended.
Here are the 6 rules that keep emergency access from becoming a permanent, unaccounted-for hole.
Normal access requests get scrutinized because there's time to scrutinize them. Emergency access gets granted specifically because there isn't. That's exactly why it needs stricter automatic controls, not looser ones.
The instinct during an incident is to grant broad access fast and sort out the details later. "Later" is precisely the step that doesn't happen unless the process forces it to.
The 6 rules for IFS Cloud emergency access
- 1. Build in a hard expiration, not a manual removal step. Emergency access should expire automatically after a set window, hours or a day, not rely on someone remembering to revoke it once the crisis has passed.
- 2. Require a named approver, even in a genuine emergency. Self-granted emergency access defeats the purpose of having any control at all. A named approver, even one reached quickly by phone, keeps the grant accountable to someone other than the person receiving it.
- 3. Log the specific reason, not just "emergency." A vague justification is useless during a later review. The specific incident, system and need should be recorded at the moment access is granted, while it's still fresh.
- 4. Trigger an automatic post-incident review. Every emergency grant should generate a mandatory follow-up review, not an optional one someone might get around to. The review is what actually closes the loop.
- 5. Scope the access to the specific need. "Give them full admin so we don't have to ask again" is exactly the shortcut that turns a contained incident into a standing, unnecessary risk.
- 6. Track emergency access as its own distinct category. Blending emergency grants into the general access request log makes them nearly impossible to specifically audit later. They need to be visibly separate from day-to-day provisioning.
Why manual removal never actually happens
Once the crisis passes, attention moves to the next thing. Relying on someone to remember to revoke emergency access is relying on exactly the step that has no natural trigger.
Why approval still matters under time pressure
Even a quick phone-call approval keeps emergency access accountable to a second person, which is the difference between a controlled exception and an unmonitored grant.
Why the post-incident review is the real safeguard
The review is what actually closes the loop, confirming the access was removed or formally converted into standing access through the normal request process, not left dangling.
The single fix that closes the most risk here
A hard, automatic expiration on every emergency grant. Everything else on this list matters, but expiration is the one control that doesn't depend on anyone remembering to act. It closes the gap by design, not by discipline.
How this shows up in an access review
Emergency access that survived past its incident is one of the most common findings in an IFS Cloud access review, precisely because it was granted correctly and just never expired.
Without a distinct category, emergency grants blend into general access history, making them nearly impossible to specifically audit or explain later.
A named approver and a logged reason are exactly what turns a defensible emergency grant into an indefensible one when neither exists.
Emergency access granted correctly at 2am and never revoked isn't a crisis anymore. It's a standing risk with a good excuse attached.
What building these rules in actually prevents
An access review finding broad, unexplained access with no record of why it was granted or whether it's still needed.
A genuine incident response getting slower because the emergency access process is either too slow to use or too risky to trust.
An auditor treating every instance of emergency access with suspicion, because none of them have a consistent, defensible process behind them.
We'll check whether your emergency access process actually closes the loop.
PermissionWorks flags emergency and privileged grants with no expiration, no logged reason, or no completed post-incident review, before an audit finds them for you.
See how this feeds into your access reviewFind the emergency access nobody's revoked yet.
Send us your current IFS Cloud user list and we'll flag privileged or emergency-style access with no expiration date, no logged reason, or no completed review.
Why is emergency access riskier than a normal access request?
Because it is granted fast, under pressure, specifically to bypass the scrutiny a normal request would get. That speed is necessary during a real incident, but it also means emergency access needs stricter automatic controls, like a hard expiration, since there is no time-pressure excuse for skipping them afterward.
Should emergency access still require approval?
Yes, even in a genuine crisis. A quick approval from a named person, even by phone, keeps the grant accountable to someone other than the person receiving it, which is the difference between a controlled exception and an unmonitored one.
What is the single most effective control for emergency access?
A hard, automatic expiration. It is the one safeguard that does not depend on anyone remembering to act once the incident has passed and attention has moved elsewhere.
How should emergency access be tracked differently from normal requests?
As its own distinct, visibly separate category. Blending emergency grants into general access history makes them nearly impossible to specifically audit or explain later, which is exactly what an access review or an auditor will ask about first.
Build in the expiration, not just the approval
Emergency access is necessary, and it is also some of the highest-risk access in your environment if it has no built-in end date.
Six rules, all of them aimed at making sure a 2am grant doesn't quietly become a permanent one.