PagerDuty fires at 2:17 a.m.
A production service is wobbling. International customers are heading for social media with angry thumbs. Dashboards are lighting up like a Christmas tree. The on-call engineer acknowledges the alert in seconds, heroically stepping into the fray.
So far, brilliant.
Then comes the tricky bit.
Broad permissions, “just in case,” isn’t least privilege. Do they actually have the access needed to investigate the issue? Can they restart the service, inspect the logs, query the right cloud resources, or change the configuration? Or are they about to spend the next 25 minutes hunting for someone with super admin rights, while the incident clock makes expensive ticking noises?
That’s the access problem hiding inside incident response.
PagerDuty controls are excellent, nay invaluable, at identifying who needs to respond, routing alerts, escalating issues, and coordinating the operational mess when systems inevitably misbehave. But once the right person is awake and staring into the caffeinated abyss, another issue raises its head:
What should that responder be allowed to do?
This is where our Trustle PagerDuty integration changes the story.
Incident response is also an access problem
Most incident-response conversations focus on detection, alerting, escalation, and mean time to resolution (MTTR). Fair enough. These things matter.
PagerDuty’s 2026 State of AI-First Operations report found that 68% of organizations lose more than $300,000 per hour during major incidents, with 34% losing at least $500,000 and 8% losing $1 million or more per hour.
So yes, speed matters. Very much so.
But speed without access is just theater. A responder who can’t reach the affected system isn’t responding. They’re spectating, with Slack open. It’s OMG o’clock, and the clock is ticking.
Many organizations solve this by granting permanent elevated access (breakglass permissions) to engineers, operators, and administrators “in case of emergency.” It works the same way as leaving every door in the office unlocked. Seemingly convenient, but a blast radius horror show.
The hidden weakness in standing privileges
Standing access is easy to justify during an incident. Nobody wants a database outage delayed because someone is waiting for approval. Nobody wants production recovery slowed by a ticket queue. Nobody wants the post-incident review to conclude: “We had the right person, but not the right permissions.”
But permanent access creates long-lived risk.
Sophos’ 2026 State of Identity Security report found that 71% of organizations suffered at least one identity-related breach in the previous year, with affected organizations reporting an average of three incidents.
Most multi-cloud environments are now stitched together from human users, service accounts and non-human identities, CI/CD pipelines, APIs, SaaS apps, and increasingly AI agents. The Cloud Security Alliance’s 2026 cloud and AI security analysis identifies insecure identities and machine permissions as a top cloud risk, noting that machine-to-human identity ratios can reach 100:1.
There are now more identities, more permissions, more paths, and more ways for attackers to turn one useful access grant into a breach. Lovely for them. Not so lovely for everyone else.
Why Access Management needs on-call details
PagerDuty controls help answer the operational question:
Who needs to act now?
Integration with Trustle helps answer the critical question:
How do we remove all access barriers to incident resolution?
And those questions belong together.
An incident workflow that alerts the right engineer but leaves them over-privileged all month isn’t least privilege. It’s “least privilege, apart from the enormous exception we’ll need to brush under the rug at audit time.”
Likewise, a workflow that keeps access locked down but slows down real incident response isn’t resilience. It’s just security cosplay. The better model is auto-approved, recorded access grants during on-call shifts. So long as they are fully revoked when the shift ends.
What the workflow can look like
Imagine the incident again.
PagerDuty detects the issue and alerts the on-call engineer. The engineer acknowledges it. They need temporary elevated access to production in AWS, Azure, or Google Cloud.
Instead of relying on permanent admin rights, they request the right entitlement through Trustle.
Because the engineer is on-call according to PagerDuty,the request is automatically granted, and automatically revoked when the time window expires.
The engineer gets moving. The organization avoids leaving standing access lying around like a rake in long grass.
This isn’t about adding friction. It’s about replacing bad friction with controlled speed. Bad friction is hunting for approvers, waiting on tickets, getting bottlenecked by processes, using shared emergency credentials, or giving everyone admin because “incidents happen.”
Controlled speed is lightweight approval, clear ownership, time limits, and audit trails.
Reducing MTTR without expanding risk
There’s a false choice hiding in many access models: Move fast, or stay secure. The goal’s not to slow responders down. The goal is to make safe access faster than unsafe access.
When PagerDuty controls identify the right responder and Trustle grants just-in-time access, organizations can reduce the operational drag of manual access requests and the security drag of standing privileges.
That matters during:
- Production outages
- Cloud misconfigurations
- Suspicious identity activity
- Failed deployments
- Customer-impacting incidents
- Emergency maintenance
- Breakglass scenarios
In each case, the access decision should be specific, temporary, approved, logged, and revoked. Never granted forever.
Audit trails matter after the incident too
Incident response doesn’t end when the service turns green.
Someone will ask what happened. Someone will ask who accessed what. Someone will ask whether the emergency access was appropriate. Sometimes that person is the internal audit. Sometimes it’s legal. Sometimes it is a regulator.
We give teams a cleaner record of access decisions around incidents:
- Who requested access
- What access was granted
- Who approved it
- How long did it last
- When it was revoked
- Whether access was used
That turns incident access into an automatic part of the response record.
The real opportunity
PagerDuty helps organizations respond when systems need attention. Trustle helps ensure the response doesn’t depend on permanent privilege.
When the alert fires, the right person can get the right access, at the right time, for the right reason, and then lose it again automatically.
Fast enough for outages. Controlled enough for security. Documented enough for audit.
Which, honestly, is a much better plan than waking someone up at 2:17 a.m. and hoping they still have admin rights from last quarter.
PagerDuty controls help get the right responder into motion. Trustle helps ensure they get only the access they need, only when they need it, with built-in approval, expiry, and audit trails. Download the Trustle free trial, and in as little as 30 minutes, see how just-in-time access can reduce standing privilege without slowing incident response.
