Identity and access management (IAM) failures in InsuranceSuite are rarely the result of bad decisions. Most of the time there was no decision.
In most cases, nothing went wrong. It simply wasn’t reviewed.
This post covers three places where IAM gaps appear consistently in InsuranceSuite implementations. The full control details are in the IAM hardening guidance, with specific control objectives for each area.
Want to stay in the loop about what’s happening for Guidewire developers? Subscribe to our developer newsletter for a monthly update on events, news, and release highlights delivered directly to your inbox.
The roles that were never touched
InsuranceSuite ships with sample roles. They exist to demonstrate what the permission model can do, rather than serving as a starting point for production. The permissions inside them are broad by design. A demo role needs to show a lot, while a production role for a commercial underwriter needs to show very little.
Nobody on most implementation teams decides to use sample roles in production. But if nobody decides to remove them either, they sit there through user acceptance testing (UAT), through staging, through go-live. Assigned to users. With permissions, nobody reviewed.
The Open Web Application Security Project (OWASP), A01:2021 (Broken Access Control) and Common Weakness Enumeration (CWE)-269 (Improper Privilege Management) both describe this failure mode as access that exceeds what a role requires, where the excess is invisible because it was inherited rather than deliberately assigned. The hardening guidance is explicit on the fix. Build from zero, not from clone-and-trim. That distinction matters because it changes what you can actually prove.
What federated identity actually covers
Teams that complete an SSO integration often assume they've handled authentication security. The Identity Provider (IdP) is connected, Hub is brokering tokens, users are logging in with corporate credentials. Job done. The problem is that connecting your IdP to Guidewire doesn't configure the IdP. That work is still yours.
Multi-factor authentication (MFA) is the obvious place this surfaces. Guidewire Cloud Platform supports SSO through your corporate IdP. MFA is not on by default in Guidewire products. It has to be configured and enforced in your identity platform. If your IdP doesn’t require a second factor for every user, that gap exists inside your Guidewire environment whether you know it or not. The National Institute of Standards and Technology (NIST) SP 800-63B is clear. Single-factor authentication isn't appropriate for systems handling sensitive personal data. InsuranceSuite handles sensitive personal data constantly.
Password policy sits in the same place. Complexity, rotation, history, compromised-credential checks: all of it lives in your IdP, not in Guidewire. Policies need to be in force before any credential gets accepted and passed to Hub. The hardening guidance covers this and references NIST SP 800-63B as the applicable baseline.
Important note:
The MFA enrollment policy for your InsuranceSuite user groups is configured in your IdP admin console, not in Guidewire. If you haven't reviewed that policy recently, that's the place to look.
Service accounts accumulate permissions too
The out-of-the-box (OOTB) role problem is about something sitting in a place that nobody removed. The service account problem is different. It's about something that gets built up gradually, one reasonable-looking decision at a time, until the result is unreasonable.
A vehicle valuation service gets its own account. A fraud detection integration needs ClaimCenter access, so someone reuses the existing account because it's already set up and adding another feels like overhead. A premium calculation service gets added the same way.
By the time anyone looks closely, one credential can read vehicle data, view all claims, and execute rating logic. If that credential is compromised, the blast radius covers everything it ever accumulated. This is the same failure mode as OOTB role inheritance. Permissions grow without anyone deciding to grow them.
Scoping each integration to its own OAuth (Open Authorization) token is a well-established application of least privilege, referenced in NIST SP 800-53 AC-6 and OWASP Security by Design principles. Each token covers exactly what that integration needs and nothing more.
Account lifecycle fits here, too. An employee leaves and IdP access gets revoked, but if deprovisioning doesn't include an API call to revoke InsuranceSuite access, the account sits there. Inactive but still fully permissioned. Automated deprovisioning triggered by your IdP on termination events is the control. A manual offboarding checklist is not. The hardening guidance recommends having this in place and tested before go-live.
The audit that ships your IAM posture, or closes it
Three problems, three different causes. OOTB roles persist because nobody deactivated them. MFA gaps exist because teams assume federation means security is handled. Service accounts accumulate because each individual reuse decision looks reasonable. What they have in common is that none of them require a wrong decision to happen. The pre-go-live audit is where they either get caught or ship.
The IAM hardening guidance at docs.guidewire.com/security covers the control objectives for each area. That's where “done” is clearly defined.