Monitor Identity Configuration Drift & Token Expirations

Outcome

Security and IT teams gain continuous visibility into two categories of identity risk that sit below the account and entitlement layer but above it in impact: configuration risks in IDP and SaaS application settings that weaken authentication controls, expand access scope, or disable security policies; and certificate and token expiration risks that — if unaddressed — cause authentication failures, integration outages, and access disruptions across the applications that depend on them. Both are surfaced as prioritized, actionable findings in Trustfusion's risk monitoring framework before they become incidents.

Two risks, one framework: Configuration risks are silent until they are exploited — a disabled MFA policy, a permissive conditional access rule, or a legacy authentication protocol left enabled can sit undetected for months while providing an open attack path. Certificate and token expiration risks are silent until they expire — and then every application and integration that depends on them fails simultaneously. Trustfusion surfaces both on the same continuously maintained posture timeline, so neither category requires a separate monitoring tool or a reactive scramble to fix.

Why this is hard without Oleria

Configuration Risks

Identity configuration risks are particularly hard to govern because they live in the settings layer of IDPs and applications — not in the access layer that most governance tools focus on:

· Configuration changes are low-visibility, high-impact events. A change to a conditional access policy, a sign-on policy modification, a legacy authentication protocol being re-enabled for a support ticket, or a Salesforce profile permission being broadened — each of these can materially weaken an organization's identity security posture in seconds. These changes are logged somewhere, but they are almost never surfaced proactively as security findings.

· IDP configuration drift is not monitored continuously. Okta and Entra ID configurations are reviewed periodically — during audits, after incidents, or as part of annual security assessments. Between reviews, configuration drift accumulates silently. A policy weakened six months ago to resolve an access complaint is still weakened today, and no one is monitoring it.

· SaaS application security settings vary widely and degrade over time. Every SaaS application has its own security configuration model — session timeout settings, password complexity requirements, IP restriction policies, API access controls. These settings are configured at deployment and rarely reviewed afterward. As applications evolve and upgrade, default settings may change, and configurations set for a previous version may no longer reflect the application's current security capabilities.

· No cross-application configuration posture baseline. Configuration risks in Salesforce, GitHub, Snowflake, and Microsoft 365 each require logging into separate admin consoles and applying separate expertise to evaluate. There is no native mechanism that aggregates security configuration posture across all applications into a single, comparable view.

· Certificates and tokens are tracked in spreadsheets, not systems. Most organizations track certificate and token expiration dates in a spreadsheet or a shared document that is updated manually and infrequently. The tracking record is stale, incomplete, and owned by whoever created it — which may be a team member who has since moved on. When a certificate expires, it is rarely because no one knew the expiry date; it is because the tracking system failed.

· Short-lived tokens and API credentials have no central tracking. OAuth client secrets, API keys, service principal credentials, and SAML certificates each have their own expiry configuration and their own renewal process — in different admin consoles, owned by different teams. No native tool tracks all of them in one place and surfaces upcoming expirations before they become failures.

· Renewal ownership is undocumented. When a certificate expires and causes an outage, one of the first questions is "who owns this?" — and the answer is frequently unclear. The original owner may have left the organization, or the integration may have been set up by a team that has since been reorganized. Without documented ownership and proactive notification, expiration events always require an emergency response.

What Oleria delivers

Oleria Trustfusion ingests identity configuration settings and certificate and token metadata from connected IDPs and SaaS applications, evaluates them against a continuously maintained security baseline, and surfaces findings before configuration drift creates exploitable gaps or expiration events cause service disruptions.

IDP security configuration posture.

For Okta and Microsoft Entra ID, Oleria evaluates key security configuration settings against a configurable baseline: MFA policy enforcement and exceptions, conditional access and sign-on policy coverage and gap analysis, legacy authentication protocol status (Basic Auth, NTLM, and other protocols that bypass MFA), session lifetime and token refresh settings, self-service password reset scope, and security defaults or baseline policy enablement. Configuration settings that deviate from the baseline generate posture findings with the specific setting, the current value, the expected value, and the security implication of the gap.

SaaS application security configuration monitoring.

For connected SaaS applications where configuration data is available via connector APIs, Oleria monitors security-relevant settings: session timeout and idle session configuration, IP allowlisting and network restriction settings, API access control configuration, password policy settings for local accounts, and application-level SSO enforcement status. Settings that weaken the application's security posture relative to the configured baseline are surfaced as configuration risk findings.

Configuration change detection.

When a monitored configuration setting changes — a conditional access policy is modified, a legacy authentication protocol is re-enabled, an application's SSO enforcement is disabled — Trustfusion detects the change and evaluates whether it creates a policy violation. Unauthorized or unexpected configuration changes that weaken security posture generate immediate findings, enabling a rapid response before the change is exploited.

Cross-application configuration posture dashboard.

Configuration risk findings across all connected IDPs and applications are surfaced in a unified posture view — enabling security teams to assess configuration health across the full environment without logging into each admin console separately.

Expired credential detection.

Certificates and tokens that have already expired — but whose integrations have not yet failed, or whose failure has not been connected to the expired credential — are surfaced as critical active risk findings. An expired certificate that is still nominally in use represents an authentication failure waiting to surface at the next authentication event or token refresh.

How it works

Configuration risk and certificate expiration monitoring runs through a four-stage continuous cycle:

Stage 1 — Ingest Configuration Settings and Credential Metadata Oleria connectors pull security configuration data from IDPs (Okta, Microsoft Entra ID) — including conditional access policies, sign-on policies, MFA settings, legacy authentication protocol status, and session configuration — alongside certificate, signing key, and client secret metadata including expiry dates and subject information. SaaS application connectors ingest security configuration settings where available via API. All data is ingested continuously so configuration changes and approaching expirations are detected as they occur, not on a periodic polling schedule.

Stage 2 — Evaluate Against Security Baseline Ingested configuration settings are compared against a configurable security baseline for each IDP and application type. The baseline defines expected values for each monitored setting — for example, legacy authentication protocols disabled, conditional access policies covering all privileged accounts, session tokens not exceeding a defined lifetime. Certificate and token expiry dates are compared against the configured warning window thresholds. Deviations from the baseline and credentials within the warning window generate typed findings with the current state, expected state, and risk context.

Stage 3 — Score, Prioritize, and Attribute Configuration risk findings are scored based on the security impact of the misconfiguration: a legacy authentication protocol enabled on a production tenant is a critical finding; a suboptimal session timeout on a low-sensitivity application is a lower-severity item. Certificate expiration findings are scored based on proximity to expiry and the number of dependent integrations. All findings are attributed to a responsible owner — the IDP admin, application owner, or IT team — based on the system and credential type.

Stage 4 — Surface, Remediate, and Evidence Configuration risk and expiration findings surface in the Posture Dashboard with filtering by risk category (configuration vs. expiration), system, severity, and days to expiry. Posture Campaigns route remediation to owners with specific remediation actions: correct the configuration setting, renew the certificate, rotate the client secret. Completion is confirmed in Trustfusion when the connector verifies the updated configuration or renewed credential. All findings, remediation actions, and resolution events are retained as audit evidence.

What good looks like

A mature configuration risk and certificate expiration monitoring program eliminates two categories of preventable identity security failure:

· No undetected configuration drift in IDP or SaaS security settings. Every security-relevant configuration setting across connected IDPs and applications is continuously monitored against the baseline. Configuration changes that weaken posture generate findings within hours. The time between a configuration weakening and its detection is measured in hours, not months.

· No legacy authentication protocols silently enabled. Legacy authentication protocol status is monitored continuously across all connected IDPs and applications. Any re-enablement of a protocol that bypasses MFA — even for a temporary support exception — generates an immediate finding with the specific protocol, the scope of exposure, and the recommended remediation.

· Zero certificates expiring without 30 days of advance notice. Every certificate and signing key across all connected systems has an active expiration finding in Trustfusion at least 90 days before expiry. No certificate expires without an assigned owner and a tracked renewal in progress. Certificate-related outages caused by unaddressed expirations are eliminated as a recurring incident type.

· Every expiring credential has a named owner and a renewal timeline. All expiration findings have an assigned owner, a renewal target date, and a tracked status in Trustfusion. The count of unowned or unaddressed expiration findings at any given time trends to zero as the program matures.

· Configuration posture included in access governance program. IDP and application security configuration posture is reported alongside account, entitlement, and authentication posture in the same Trustfusion dashboard — giving security leadership a complete identity risk picture rather than a partial view limited to the access layer.

· Audit evidence for configuration controls on demand. The configuration posture history — what settings were in place, when they changed, what findings were raised, and what remediation was taken — is retained in Trustfusion and exportable for SOX, SOC 2, ISO 27001, and PCI DSS auditors who require evidence of monitored and controlled IDP and application security configurations.

Frequently Asked Questions

What specific IDP configuration settings does Oleria monitor for Okta and Entra ID?

For Okta, Oleria monitors: sign-on policy coverage and MFA enforcement per application, legacy authentication protocol status, session lifetime and idle timeout settings, self-service password reset configuration, and threat insight and suspicious activity detection settings. For Microsoft Entra ID, Oleria monitors: conditional access policy coverage and gap analysis (including which accounts are not covered by any policy requiring MFA), legacy authentication protocol blocking status (Basic Auth, NTLM, legacy Exchange protocols), security defaults enablement, Entra ID Protection risk policy configuration, and token lifetime policy settings. The specific set of monitored settings is configurable and expands as connector capabilities grow.

What types of certificates and credentials does Oleria track for expiration?

Oleria tracks expiration metadata for: SAML application signing certificates in Entra ID and Okta (the certificates used to sign SAML assertions for federated applications — when these expire, SSO for every dependent application fails); OIDC signing keys and OAuth 2.0 client secrets for IDP-registered applications; service principal certificates and client secrets in Entra ID (used by applications and automation to authenticate to Microsoft APIs); and where exposed via connector APIs, API credentials and integration tokens in connected SaaS applications. The scope of expiration tracking expands with each connector added to the environment.

How does Oleria detect configuration changes — does it compare against a fixed baseline or a dynamic one?

Both approaches are used together. Trustfusion maintains a configurable security baseline for each IDP and application type — a set of expected values for monitored settings that reflects the organization's security policy. When a setting deviates from the baseline, a finding is generated. In addition, Trustfusion tracks configuration change events — detecting when a setting value changes between connector polling intervals, regardless of whether the new value violates the baseline. Change detection enables rapid response to unexpected modifications even for settings not currently in the baseline, and creates a change history that is valuable for both security investigation and compliance evidence.

Does Oleria monitor configuration risks in SaaS applications beyond the IDP?

Yes, for connected SaaS applications where security configuration data is available via the connector API. The scope of configuration monitoring varies by application and connector — some applications expose rich configuration APIs (Salesforce, Microsoft 365, GitHub); others expose limited configuration metadata. Where configuration data is available, Oleria evaluates it against a configurable baseline and surfaces deviations as findings in the same posture framework as IDP configuration risks. The configuration monitoring scope for each application is documented in the connector specification.

How does this use case relate to our existing CSPM or security configuration management tools?

Cloud Security Posture Management (CSPM) tools monitor infrastructure and cloud platform configuration — IAM policies, storage bucket settings, network security groups. Oleria's configuration risk monitoring focuses on the identity and authentication layer: IDP security settings, application-level authentication configuration, and the credentials (certificates, secrets, signing keys) that underpin identity federation and API authentication. The two capabilities are complementary — CSPM governs the infrastructure posture; Oleria governs the identity posture. Most organizations benefit from both, and findings from Oleria's identity configuration layer often surface issues that CSPM tools are not designed to detect.

Which compliance frameworks require monitoring of identity configuration and certificate management?

SOC 2 Type II (CC6.1 and CC7.2) requires that security configurations be monitored and that anomalies be detected and addressed — configuration drift and expired certificates are directly relevant. ISO/IEC 27001 (A.12.1 Operational procedures and A.14.2 Security in development and support) requires that system configurations be controlled and monitored. PCI DSS v4.0 (Requirements 2 and 8) requires that system components be configured securely and that authentication credentials be managed — expired certificates on cardholder data environment integrations are a compliance gap. NIST SP 800-53 (CM-6 Configuration Settings and IA-5 Authenticator Management) mandates monitoring of configuration settings and lifecycle management of authenticators including certificates. Trustfusion's configuration posture history and certificate lifecycle records provide the evidence these frameworks require.

Continuously monitor identity risk across every account before it causes a security failure