Skip to main content

Changelog

All notable changes to Prism and its documentation are listed here, with the most recent entries first.

August 2026​

API Reference​

Released: August 2026

Prism's customer API now has published reference documentation, at API Reference. Thirty-six operations across six groups (users, groups, permission sets, permission set assignments, AWS accounts and account contacts), each with its request body, response shape, status codes, and the behaviour you would otherwise only learn by trying it.

It is written by hand against the code rather than generated from it. That is slower, and it is the point: every request and response was read off the handler that serves it. A generated specification would have described what the code appears to promise; this one describes what it does: a pageSize that resets rather than clamps, creates that answer 200 rather than 201, a DELETE that requires a request body, and arrays that come back null when empty in one response and [] in another, sometimes in the same object.

Highlights​

  • Examples arrive already filled in. Open the reference from API Tokens in your Prism console and every code sample on the site carries your own API host and tenant. Nothing to type and nothing to look up: the port is non-standard and the tenant is a path segment, so neither is guessable from the outside.
  • Snippets in every language the generator supports (cURL, Python, Go, Java, JavaScript, C#, PHP and more, each with its own variants), all produced from the same request, so they cannot disagree with one another.
  • The specification is downloadable at /openapi.yaml. OpenAPI 3.1, ready to import into Postman or Insomnia, or to hand to a client generator.
  • A test keeps it honest. A check in the backend walks the live router on every build and fails if the reference documents an endpoint that does not exist, or if a route exists that nobody has classified as public or internal. The documentation cannot quietly drift away from the code.

Worth knowing​

  • The API answers on port 8090, not 443: https://<your-host>:8090/api/v1/customers/<tenant>, where the tenant is the slug from your console URL. The customer UUID works in its place.
  • Authenticate with the X-API-Token header, using a token minted under API Tokens in the console. A token carries full access to its tenant (there are no read-only or per-resource scopes yet), so treat one the way you would treat an administrator's password.
  • There is deliberately no "Try it" button. Running requests from a documentation page would mean pasting a live token into a web page, so the reference never asks for one and never stores one. The snippets are for copying into your own terminal.
  • The reference describes the API as it behaves, not as it was intended to. Where an endpoint returns a status code that is arguably the wrong one, or accepts a field and then ignores it, the page says so rather than papering over it.

Not in this release​

  • Organization Services endpoints (Security Hub and its capabilities, and StackSets) are not covered. They authenticate with a portal session rather than a static API token, so a token cannot reach them.
  • JIT access endpoints, for the same reason: they require a role that API tokens do not carry.
  • Scoped tokens. Read-only and per-resource scopes are the obvious next step and are not here yet.

Amazon VPC IPAM (Organization Services)​

Released: August 2026

VPC IPAM joins the Security Hub as its ninth capability, and the first one that is not about security. The eight capabilities before it answer questions about risk: what is misconfigured, what is under attack, what is exposed, what is unpatched. VPC IPAM answers a different question entirely: where is your organization's IP address space, who owns it, how much of it is in use, and where does it collide?

It is grouped under Security Hub because it is deployed the same way every other capability is (across your enrolled accounts, through each account's own switch role, with no AWS Organizations management-account access), not because it is a security tool. It is described as networking throughout the product and the documentation for exactly that reason.

Highlights​

  • A discovered address inventory across every enrolled account. Every VPC, subnet and Elastic IP CIDR AWS can see, in one table, with the owning account, the region, utilization, and its compliance and overlap state. Cross-account CIDR overlap (two accounts using the same range, the classic blocker for peering and transit) is reported directly, with no AWS Organizations integration involved.
  • The full pool hierarchy. Scopes, top-level pools, regional pools and nested pools to a depth of ten; provision and deprovision CIDRs; allocate and release. Allocations are shown separately from the discovered inventory on purpose: allocations are what IPAM handed out, the inventory is what IPAM found, and a VPC created outside a pool appears in one and not the other. That gap is the compliance story.
  • Public IP Insights, the idle Elastic IP and public IPv4 cost dataset, alongside per-CIDR address history.
  • Enrollment and discovery health on one page. Each account expands to a line per region carrying both Prism's own enrollment phase and AWS's discovery status, so "why is this account missing from every table" is answerable without correlating two screens. A revoked AWS RAM share shows as not-found rather than as silence.
  • No management account, ever. Prism enrols each account through its own switch role, creates a resource discovery there, and shares it to the host account with AWS RAM. There is no delegated administrator, no trusted access, and no organization-wide fan-out.

Worth knowing before you enable it​

  • This one costs money, and it is the only capability that does. VPC IPAM Advanced tier is mandatory for any multi-account use. Before anything is created, the setup wizard counts the real number of active IP addresses in the accounts and regions you have selected and shows an estimate; you cannot proceed without acknowledging the charge, and the acknowledgement is enforced by the server, not just the browser.
  • The IPAM bill lands on the host account, and Prism cannot redistribute it. AWS charges the account that owns the IPAM for every active IP it manages. Moving the charge to each resource's own account requires AWS Organizations integration and an IPAM created by a delegated administrator, neither of which Prism uses, by design. Only the accounts you enrol are metered, never your whole organization. The host account is chosen once and cannot be changed afterwards.
  • The inventory is empty at first, and that is not a fault. AWS's discovery is a periodic background sweep, not a live query. The first sweep after creating an IPAM can take up to about 20 minutes; a newly added account typically appears within four to seven minutes. "Enabled, association active, zero rows" is a normal steady state during that window, and there is nothing to retry.
  • Utilization is blank, not zero, for IPv6. AWS states that IPv6 address-space utilization cannot currently be calculated. Prism draws no bar rather than drawing a 0% one, because "0% used" about address exhaustion would be a false reassurance.
  • Enrollment is capped at four member accounts by default. AWS's default quota is five resource-discovery associations per IPAM, and the host's own association consumes one. Prism reads your account's applied quota rather than assuming the default, refuses up front rather than half-enrolling, and can file an AWS quota-increase request sized to your account count, but only with your explicit approval, because it opens a support case on your account.
  • Prism will never delete one of your VPCs, which is why teardown can legitimately stop. If a member account holds a live VPC allocated from a pool, AWS's only remedy is to remove that resource; Prism reports the pool as blocked, names the resource and the account, and waits. A Force delete escape hatch is offered once the ordered teardown has exhausted its options, never as a first action, and never silently.

Not in this release​

  • IPAM Policies and prefix-list resolvers. Both are real AWS features and both are deliberately deferred, with their route namespaces left unclaimed so adding them later does not reshape what is here.
  • Public-scope pools. Prism does not create them, because AWS refuses a cascading IPAM delete while a public-scope pool exists, which would remove the only in-product way to stop the meter.
  • Changing where the bill lands. MeteredAccount is displayed read-only. This is permanent, not deferred.
  • No findings. VPC IPAM emits no findings, so it has no severity, no Overview stat card, and no entry in the unified findings inbox. A card counting its findings would permanently read zero, which is why it does not have one.

See VPC IPAM for the full guide, and VPC IPAM Issues for the empty-inventory, blocked-pool and billing questions.

OIDC Custom Applications​

Released: August 2026

Custom Applications now speak OpenID Connect as well as SAML 2.0. Applications built on modern authentication libraries (including single-page applications, which SAML never served well) can be registered against a single discovery URL instead of a metadata document and a signing certificate.

Highlights​

  • A protocol choice when registering an application, with the SAML 2.0 flow unchanged and OIDC alongside it. The documentation splits to match: a short overview with a protocol-choice guide, then a page for each protocol.
  • You choose the client ID. Rather than being handed an opaque identifier, you name the client yourself: letters, digits, ., _ and -, up to 120 characters. It is fixed once the application is created, because it is baked into the application's configuration.
  • Redirect URIs are validated strictly, because they are a security boundary. https:// is required with no exceptions (http:// is rejected for every host, including the 127.0.0.1 and ::1 loopback addresses), and a wildcard is accepted only as a trailing /* after a complete host, never alongside a query string. https://app.example.com* (the same pattern without the slash) is rejected, because prefix matching would also match https://app.example.com.attacker.com. A # fragment is rejected outright; hash-routed single-page applications register the fragment-less prefix with a trailing wildcard instead: https://app.example.com/* is matched as a prefix against the whole incoming address, fragment included, so it accepts https://app.example.com/#/callback with no change to the application.
  • PKCE S256 is enforced for public clients and cannot be disabled. A single-page application cannot hold a secret, so the proof-of-possession takes its place. The weaker plain method is never accepted, for any client.
  • Post-logout redirect behaviour is an explicit three-way choice, not a field you leave blank: inherit the redirect URIs, list specific URIs, or allow none. An empty post-logout list conventionally means inherit everything, so an admin clearing the field to lock sign-out down would have got the opposite of what they intended. Making it a choice removes the trap.
  • Connection details are split into per-realm and per-client values, so it is clear which values are shared by every application in your tenant (the issuer, the discovery URL, and the authorization, token, userinfo, JWKS and end-session endpoints) and which belong to this application alone. The discovery URL is the single value most OIDC libraries need.
  • Client secrets are never stored by Prism. They are read from your realm on demand, so revealing one re-fetches the current value rather than showing a cached copy. Secrets are roughly 86 characters, which is longer than many configuration fields expect.
  • Front-channel and back-channel logout URLs let an application clear its own session when a user signs out of Prism.

Worth knowing before you integrate​

  • A Prism assignment does not control who can log in. Assigning users or groups to an application governs the portal tile and the role claims in the token; it does not gate authentication, for OIDC or SAML. Prism authenticates, and the application authorizes, using resource_access.{clientId}.roles from the access token.
  • Client roles are in the access token, not the ID token. An application that inspects only the ID token, which is common for pure-SSO integrations, will find no roles there and may conclude role mapping is broken. Read the access token, or call the userinfo endpoint.
  • Regenerating a client secret is a hard replace with no grace period. There is no dual-secret rotation window: the application breaks the instant the secret is regenerated and stays broken until the new value is deployed. The documentation includes a runbook for responding to a leaked secret.

Not supported in this release​

  • IdP-initiated SSO. OIDC has no equivalent of a SAML IdP-initiated sign-in, so a login must begin at the application. The portal tile deep-links to the application's Home URL and the application starts its own login, which is seamless for the user because the Prism session already exists. Use SAML where a true IdP-initiated hand-off is required.
  • Mobile and native desktop applications. Both of the redirect URI forms a native application uses are rejected: private-use schemes such as com.example.app:/oauth2redirect (RFC 8252 §7.1), and http:// loopback addresses. A native application therefore has no valid redirect URI to register. Public clients with enforced PKCE S256 are fully supported for single-page applications, which return to an ordinary https:// address.
  • http:// redirect URIs of any kind, including loopback. There is no local-development exception; register an https:// address in every environment.
  • A # fragment in a redirect URI, Home URL, post-logout redirect URI, or back-channel logout URL. The identity server refuses to store one on the first three (RFC 6749 §3.1.2 forbids a fragment in a redirection endpoint), so a fragment-bearing URI could never be saved. A fragment on a back-channel logout URL would be stored and then silently dropped, because a fragment is never transmitted in an HTTP request, so Prism rejects that too. Hash-routed single-page applications are not affected: register the fragment-less prefix with a trailing wildcard, https://app.example.com/*, which accepts the hash route unchanged. The front-channel logout URL is the one field where a fragment is both stored and delivered: the sid and iss parameters are inserted before the #.
  • Changing a client ID, or converting between a public and a confidential client, after creation. Both are fixed at creation; register a new application instead.

See Custom Applications for the protocol-choice guide and OIDC Applications for the full field reference, redirect URI rules, and client secret handling.

SAML 2.0 Identity Providers​

Released: August 15, 2026

Prism now federates SAML 2.0 identity providers alongside the existing Google, Microsoft, and custom OIDC options. Enterprises standardised on Microsoft Entra ID, Okta, Google Workspace, or ADFS can onboard without an OIDC client.

Highlights​

  • New SAML 2.0 tab in Admin Portal > Identity Providers, sitting alongside Google IdP, Microsoft IdP, and Custom IdP. A SAML provider counts toward the same per-type limit as the others, and a realm running SAML alone is enough to enable IdP-only login.
  • Three ways to configure a provider, converging on one set of fields you can still adjust by hand before saving: import from a metadata URL, upload a metadata XML file for identity providers Prism's servers cannot reach over the network, or enter the values manually.
  • The three Service Provider values are surfaced in the UI, so nothing has to be assembled by hand: the ACS / Reply URL, the SP Entity ID, and the SP metadata descriptor URL, each with a copy button and a Copy all action. They appear as a preview while you fill in the form and, authoritatively, in a Connection details dialog after the provider is created, which is where the final alias, and therefore the final ACS URL, is confirmed.
  • An email attribute mapper is created automatically. Prism configures exactly one mapper, which copies the identity provider's email claim onto the Prism user's email address. Federated logins are then matched to existing Prism accounts by email, with no attribute mapping to configure.
  • Metadata imports are validated, not trusted. Documents fetched over HTTPS only, size-capped, and rejected outright when they carry no identity provider descriptor (which is what pasting Service Provider metadata produces), or when they are multi-entity aggregates.
  • Certificates are handled in the form you actually have them in. Paste a full PEM block and the armor and line breaks are stripped for you; comma-separate two certificates to roll through a rotation with no window of failed logins.
  • Terraform support: prism_identity_provider accepts type = "saml", with the same configuration keys as the API.
  • A Microsoft Entra ID walkthrough covering the claims to check, the per-application federation metadata URL to copy, and the Entra behaviors that are not bugs.

Not supported in this release​

  • Single logout (SLO). Signing out of Prism ends the Prism session only; the identity provider's session is untouched.
  • IdP-initiated sign-in. Sign-in must start at the Prism login page. Microsoft Entra ID's Test single sign-on button, the My Apps portal, and the Microsoft 365 app launcher all perform IdP-initiated sign-in and will fail.
  • Assertion encryption. Assertions are signed and validated, but encrypted assertions are not accepted.
  • Just-in-time account creation. Prism links a federated login to an existing Prism account and never creates one. A user who authenticates successfully at the identity provider but has no Prism account is refused.

See Identity Providers > SAML 2.0 for the field reference and Microsoft Entra ID (SAML) for the full walkthrough.

AWS IAM Access Analyzer (Security Hub)​

Released: August 2026

AWS IAM Access Analyzer joins the Security Hub as its seventh capability, bringing access analysis alongside compliance posture, threat detection, data security, vulnerability management, security investigation, and AWS Config recording.

Access Analyzer uses automated reasoning over your resource policies to prove which principals can reach a resource, and reports every grant that reaches outside its zone of trust. It also tracks when IAM roles, access keys and console passwords were last used, and reports the ones that have gone unused.

Highlights​

  • Two families of finding in one place: external-access findings, which name the resource policies granting access outside the account's zone of trust, and unused-access findings, which name the IAM roles, users, access keys, passwords and permissions that have gone unused. Both are browsed through one list and one dashboard, and both appear in the unified Security Hub findings inbox alongside the other engines'.
  • No delegated administrator: like Amazon Inspector, Access Analyzer uses a flat peer model. Each account gets its own analyzers, created through its own access role. No administrator account is nominated, no invitations are sent, no AWS root email addresses are needed, and no AWS management-account access is ever required.
  • External access is free; unused access is opt-in and off by default: external-access analyzers cost nothing, however many accounts and regions you cover. Unused-access analysis is billed by AWS at $0.20 per IAM role or user, per month, per account, so it is a deliberate opt-in with its own step in the wizard and its own tab in Settings.
  • One unused-access analyzer per account, in the home region only: IAM is a global service, so an unused-access analyzer in a second region would report the same roles again under different finding IDs, and be billed again. Prism creates exactly one per account. Adding a linking region therefore never multiplies your unused-access bill.
  • Severity is computed by Prism, because AWS ships none: AWS IAM Access Analyzer has no severity field at all, in the console or the API. Prism derives one from what the finding reports (public plus a write action is Critical, public alone is High, cross-account is Medium) and for unused access raises a credential that has never been used one band above one that merely went quiet. The full mapping is documented, because a customer diffing against the AWS console will find nothing there to compare it to.
  • Existing analyzers are adopted, never destroyed: AWS permits only one analyzer per type, per account, per region, and that quota is not adjustable. Where an analyzer already exists, Prism reads it instead of failing, marks the cell Adopted, and never deletes it on any teardown path. Deleting an analyzer destroys every finding it ever generated, and those findings are the customer's. Ownership is decided by a Prism tag on the analyzer, never by a name match.
  • Prism's phase and AWS's analyzer status are shown side by side: a row can read Enabled in Prism's column and FAILED in AWS's, and both are true: Prism created the analyzer, and AWS subsequently failed it. AnalyzerStatus and StatusReason are surfaced rather than folded into one chip, because a failed analyzer produces no findings and otherwise looks exactly like a clean account.
  • Standing, enumerated permissions: a named CKPrism-AccessAnalyzer-Permissions policy grants exactly six Access Analyzer actions on each enrolled account's access role, plus creation of the AWSServiceRoleForAccessAnalyzer service-linked role scoped by condition to access-analyzer.amazonaws.com. No service wildcards, no AWS Organizations actions, and no archive-rule actions.

Disclosure: zone of trust, and why Prism's findings are noisier than the AWS console's​

Prism creates account-scoped analyzers. An analyzer's zone of trust is what it treats as trusted, and everything outside it is reported as external access. AWS offers two scopes, and they answer different questions:

Analyzer scopeZone of trustA grant to another account in your own AWS Organization is…
Account (what Prism creates)The single AWS accountreported as an external-access finding
OrganizationThe whole AWS Organizationtreated as trusted, and not reported

So if your logging account's S3 bucket policy grants a role in your production account, and both are yours and in the same AWS Organization, Prism reports it as external access. An organization-scoped analyzer would say nothing about it.

Why Prism does it this way. An organization-scoped analyzer can only be created by the AWS Organizations management account, or by an account registered as a delegated administrator for Access Analyzer. Prism deliberately holds neither: it enables every capability through each enrolled account's own switch role, never touches your management account, never registers a delegated administrator, and its policy carries no organizations:* action at all. An account-scoped analyzer is the only kind Prism can create inside that boundary.

What that means in practice. Prism's external-access findings are stricter and noisier than what you would see in the AWS console had you enabled an organization analyzer yourself. If you treat your organization as one trust boundary, a large share of your findings will be intra-organization grants you already know about. They are not false positives (an intra-organization grant is real cross-account access, and an account-scoped analyzer is right to name it), but they are answering a narrower question than the console's org analyzer would. Read the Principal field before triaging, prioritise by the Public flag rather than by the count, and, if you want the organization-wide view as well, create an organization-scoped analyzer yourself in the AWS console: it coexists with Prism's, because the quota is per account and per type.

Also worth knowing before you enable it​

  • "Free" applies to Access Analyzer, not necessarily to the whole pipeline. AWS automatically forwards Access Analyzer findings to AWS Security Hub CSPM in accounts where Security Hub is enabled. That is done by AWS, is not something Prism turns on, and cannot be turned off from Prism. Security Hub CSPM meters finding ingestion and charges for it beyond its free tier, so in an account running both, free Access Analyzer findings can still produce a Security Hub ingestion charge.
  • What a teardown leaves behind. Adopted analyzers survive removal and disable, for the reason above, and keep producing findings (and, where they are unused-access analyzers, keep billing) until you delete them yourself. The AWSServiceRoleForAccessAnalyzer service-linked role also survives, because it is shared by every analyzer in the account including ones Prism does not own. Unused-access charges may not be prorated mid-month.

See IAM Access Analyzer for the full guide.

Amazon Detective (Security Hub)​

Released: August 2026

Amazon Detective joins the Security Hub as its sixth capability, bringing behavior-graph investigation alongside compliance posture, threat detection, data security, vulnerability management, and AWS Config recording.

Highlights​

  • Behavior-graph investigation across your organization: one administrator account owns a behavior graph built from AWS CloudTrail management events, Amazon VPC flow logs, and Amazon GuardDuty findings, and every other account joins it by invitation. Detective builds one behavior graph per region, so each region you cover is separate coverage.
  • Investigations, not posture findings: each finding is an investigation report naming the IAM user or role examined, the severity Detective assigned, the analysis status, and the time window analysed. They appear in the unified Security Hub findings inbox alongside the other engines'.
  • Detective does not create investigations on its own: it recommends entities worth investigating, and a report exists only once someone runs an investigation. Prism reads those reports and never starts or re-triages one, so an empty list is Detective's expected steady state until an investigation is run from the AWS console. The dashboard and the findings list both say so rather than showing a bare "no results".
  • Unrated investigations are shown as unrated: Amazon Detective returns severity with the full investigation report rather than in the list, so a freshly refreshed investigation has none until it is opened. A separate Unrated tile carries those rows instead of folding them into Informational or dropping them, so the severity strip always adds up.
  • Root-email verification surfaced where it fails: AWS verifies each member's real root user address asynchronously, so a wrong address fails several minutes after the enrollment appears to succeed. A verification-failed account gets an inline root email field pre-filled with the rejected address, because retrying with the same address fails identically.
  • Two status columns, deliberately: every row shows Prism's phase and Amazon Detective's own member status side by side, always. They frequently disagree while both are true, ACCEPTED_BUT_DISABLED being the important case: the account joined the graph and is not ingesting, and the action is Start monitoring, not Retry.
  • Standing, enumerated permissions: a named CKPrism-Detective-Permissions policy grants exactly eleven Detective actions on each enrolled account's access role, with no service wildcards, no AWS Organizations actions, no service-linked role, and no permission to start or re-triage an investigation.
  • Unavailable rather than broken on unpaired self-hosted installs: a self-hosted deployment not paired with CloudKeeper SaaS cannot resolve member root emails, so Detective's capability card shows the reason in place of an Enable button instead of offering an enable that would fail.

See Detective for the full guide.

Amazon Inspector (Security Hub)​

Released: August 2026

Amazon Inspector joins the Security Hub as its fifth capability, bringing software vulnerability management alongside compliance posture, threat detection, data security, and AWS Config recording.

Highlights​

  • Vulnerability scanning across your estate: continuously scan EC2 instances, ECR container images, Lambda functions, and code repositories for known CVEs, insecure code, and unintended network exposure.
  • No delegated administrator: Inspector uses a flat peer model. Each account is enabled independently through its own access role, no administrator account is nominated, no invitations are sent, no AWS root email addresses are needed, and no management-account access is ever required. Prism, not AWS, aggregates the results.
  • Five selectable scan types: choose EC2, ECR, Lambda dependencies, Lambda code, and code repositories independently. Inspector bills per resource scanned, so this selection is the main cost lever, and it can be changed at any time from Settings.
  • Top CVEs across the organization: rank the vulnerabilities generating the most findings estate-wide, with the highest Inspector score recorded for each and whether a fix is published.
  • Severity breakdown including UNTRIAGED: six severity tiles. UNTRIAGED means AWS has not yet assigned a severity, which is not the same as informational.
  • Fix availability: see how many findings already have a vendor fix, to separate what you can remediate today from what is waiting on a vendor.
  • Per-account retry and Fix roles: accounts enrol independently, so partial success is a normal outcome. Failed accounts are listed individually with a Retry action, and a Permissions tab scans every account's access role and re-applies the required policy.
  • Active-only findings cache: each refresh caches the findings AWS currently reports as active and prunes those it no longer reports, so remediated vulnerabilities drop out instead of accumulating.

See Inspector for the full guide.

July 2026​

Security Hub (Organization Services)​

Released: July 2026

Prism now offers Security Hub as a second Organization Services capability alongside CloudTrail. It centralizes cloud security posture, threat detection, and data security across every AWS account in your organization, under one umbrella with four capabilities.

Highlights​

  • Security Hub CSPM: enroll all member accounts under a delegated administrator, evaluate them against up to six AWS compliance standards, and drill down from standard to control to individual resource check with control-based compliance scores.
  • Amazon GuardDuty: enable threat detection across accounts and regions, with a threat dashboard, per-type and per-account breakdowns, and an archive/unarchive workflow.
  • Amazon Macie: enable S3 data-security posture across accounts and regions, with an S3 bucket posture inventory (public access, encryption, external sharing), policy and sensitive-data findings, and optional automated sensitive-data discovery (off by default, billed per GB of data inspected).
  • AWS Config foundation: Prism provisions and manages the AWS Config recorders that Security Hub standards depend on, with minimal or record-all scope and a one-click inline enable prompt.
  • Add engines anytime: enable a second engine after your first from the Configuration page.
  • Organization Services users: grant Organization Services access to non-admin realm users without giving them the Admin Portal.

Security Hub is available as a beta feature. See Security Hub for the full guide.

June 2026​

Google Workspace Sync​

Released: June 2026

Prism can now provision users and groups from Google Workspace automatically. Because Google Workspace cannot push outbound SCIM to a custom endpoint, Prism pulls the directory from Google's Admin SDK on a schedule and reconciles it into your realm. It is the Google equivalent of SCIM provisioning.

Highlights​

  • New Google Workspace Sync card in Preferences > SCIM: connect a Google service account, set the impersonated admin and sync interval, then enable scheduled sync.
  • Provisions user create and update, suspend and reactivate, group create and delete, and group membership. A manual Sync now runs an immediate reconciliation.
  • Deletions are safe: a user removed from Google is disabled, not deleted (reversible), and an existing Prism user that matches by email is adopted rather than duplicated.
  • Email addresses are immutable and group names are not renamed on sync, which protects downstream references such as permission-set assignments.
  • Users and groups from other identity providers (Okta, Microsoft Entra ID) or created manually are never modified or deleted.

See Google Workspace Sync for the full guide.

Read-Only Admin Access​

Released: June 2026

Admins can now be granted read-only access to the Prism Admin Portal. A read-only admin can sign in and view everything, including the configured permission sets and the SCP/Organizations policies currently applied, along with users, groups, assignments, accounts, and identity providers, but cannot create, edit, or delete any resource.

Highlights​

  • New Read-only access level, selectable when promoting a user in Preferences > Admin Management.
  • Switch an existing admin between Full admin and Read-only at any time with the per-row Make Read-only / Make Full Admin action (Super Admin only).
  • All modification controls are disabled for read-only admins, and any change is blocked server-side, view-only is enforced, not just hidden in the UI.
  • Scoped to the Admin Portal only: a read-only admin's JIT access and AWS SSO sign-in are unaffected.

See Preferences > Admin Management for the full guide.

May 2026​

Passwordless Passkeys​

Released: May 2026

Workforce users can now sign in with a passkey, a FIDO2 credential (platform biometrics, a phone, a hardware security key, or a password manager), instead of a password. Admins enable it per realm and enforce it per user alongside the existing authenticator-app (TOTP) option.

Highlights​

  • New Passwordless Passkeys toggle in Preferences > Admin Management enables passkey sign-in for the realm.
  • Enforce Authenticator app or Passkey per user from the Multi-Factor Authentication panel.
  • Enrolled at next login; afterward users sign in passwordless via the "Sign in with passkey" button. Password + authenticator-app stays available as a fallback.

See Preferences > Admin Management for the full guide.

Permission set Relay state​

Released: May 2026

Permission sets now accept an optional Relay state, an AWS console URL the user is forwarded to immediately after federation. Use it to land each permission set on the page that matches its purpose (an EC2 operator goes to the EC2 console, a billing reviewer goes to the billing console, and so on).

Highlights​

  • New Relay state field on the permission set create and edit forms (up to 320 characters; AWS-allowed character set).
  • Configured value is shown on the permission set detail view.
  • Takes effect on the next sign-in, existing assignments do not need to be re-issued.
  • Empty relay state preserves today's behavior: users land on the default AWS console homepage.

See Permission Sets > Relay state for the field reference and ready-to-paste examples.

February 2026​

Prism Documentation Site - Initial Release​

Released: February 2026

The Prism documentation site has been published with comprehensive coverage of all three Prism portals and platform capabilities.

What's Included​

Getting Started

  • Prerequisites and system requirements
  • Initial setup guide for new organizations
  • First login instructions for all portals
  • Quick start guides for admins, JIT users, and CloudTrail users

Admin Portal Documentation

  • Dashboard overview
  • User management: create, edit, delete users, manage MFA, assign to groups
  • Group management: create, delete, manage members
  • Permission set management: create, edit, delete, AWS managed policies, inline IAM policies
  • Assignment management: create, delete, user assignments, group assignments
  • AWS account management: onboard, rename, manage owners, delete
  • Identity provider configuration: Google OAuth, Microsoft OAuth, custom OIDC
  • Custom application configuration: SAML applications
  • Preferences: admin management, SCIM configuration, API tokens, replication, log export settings
  • Logs: audit logs, access logs

JIT Access Portal Documentation

  • Authentication and portal access
  • Request access: standard and custom permission sets
  • My requests and active sessions tracking
  • Approver guide: pending approvals, request history, approve/reject workflow, manage sessions, owned accounts

CloudTrail Documentation

  • Trail list overview
  • Trail creation wizard: trail settings, account selection, S3 bucket configuration, event configuration
  • Trail detail view and trail editing
  • Event types: management events, data events, insight events, network activity events

Troubleshooting

  • Login and authentication issues
  • SSO configuration problems
  • Permission and access errors
  • JIT request issues
  • CloudTrail setup issues