IA-13 Identity providers: requirements and evidence

What IA-13 asks for and why teams struggle with it

An audit or system authorization that requires IA-13 usually arrives with a specific problem: the control is not selected in any SP 800-53B baseline, so it does not appear in a low, moderate or high baseline by default. Your organization must add it by tailoring a baseline or by applying an overlay, and the assessor will expect to see that decision recorded in the system security plan. Start by confirming with your assessor or authorizing official whether IA-13 is in scope, and if so, which tailoring decision or overlay brings it in. The control itself asks the organization to employ identity providers and authorization servers, under a defined policy and defined mechanisms, to manage the identities, attributes and access rights of users, devices and non-person entities. Those decisions feed the authentication and authorization choices made elsewhere in the system.

The control addresses a practical risk: when identities and access rights are spread across applications, each with its own local accounts, no one can say reliably who or what can reach which resource, or why. Teams struggle with it for three reasons. Identity sprawl means accounts exist in directories, applications, cloud consoles and scripts that were never reconciled. Service accounts and API clients are often created by developers for a single integration and never documented, so they fall outside any review. Ownership of attributes is unclear: HR systems, managers and application teams each assume another group maintains role and group membership, so the attributes that drive authorization decisions go stale. Before any tooling is chosen, inventory these identity sources and name an owner for each attribute.

The control was added in SP 800-53 Release 5.1.1 (7 November 2023) together with three control enhancements, IA-13(1) through IA-13(3). In this page they are covered only as a group: one concerns key protection for the identity provider, one concerns assertion and token verification, and one concerns token management. Each enhancement is a separate design decision with its own evidence, so plan the assessment of the base control first and then decide which enhancements your system needs. Confirm the current enhancement wording in the NIST CPRT catalog before writing test procedures, because enhancement titles and discussion text are the authoritative source for what an assessor will check.

Which identity systems fall under IA-13 once you add it

IA-13 covers the identity providers and authorization servers that make authentication and authorization decisions, so the first work is deciding which of them sit inside the system's boundary. Each card below is a scoping decision that changes how much evidence you must produce and who produces it.

Identity providers inside the boundary

Start by listing every identity provider and authorization server that issues or validates credentials for the system, including directory services, single sign-on brokers and token issuers. Any component that makes an authentication or authorization decision for the system is a candidate for the boundary, and each one needs its policy, configuration settings and test results documented. Confirm with the system owner whether a broker that only forwards requests to another provider is in scope, because that answer decides whether one component or two must be assessed.

User, device and non-person identities

IA-13 names three identity types: users, devices and non-person entities such as service accounts, workloads and API clients. Inventory each type separately, because a provider may cover people well while leaving machine identities issued by a different path. Non-person identities are often the largest gap, since they tend to have long-lived secrets and no named owner. Record which identity source backs each type so an assessor can trace a sample identity from issuance to access decision.

Inherited identity services outside your control

Cloud directory services, hosted single sign-on and managed Kerberos or certificate services may be operated by a provider you do not control. Decide whether each one is inherited through a documented agreement, treated as a separate system with its own assessment, or excluded with a stated reason. Request the provider's control evidence for identity, including how it protects signing keys and manages token lifetimes, and confirm that the evidence covers your tenant rather than the provider in general.

Key and token protection components

The IA-13 enhancements address protection of cryptographic keys and the verification and management of assertions and tokens. Identify where signing keys, encryption keys and token secrets are generated, stored and rotated, because a key store or secrets engine often becomes a separate component with its own evidence. Confirm that the key store is inside the boundary whenever the identity provider relies on it, and that rotation and revocation events are logged for review.

Tailoring a baseline or adding an overlay

SP 800-53B does not select IA-13 in the low, moderate, high or privacy baselines, so your system adds it deliberately through baseline tailoring or an overlay. A tailored baseline keeps the decision inside your own security plan, while an overlay applies a shared set of requirements across several systems. Record the decision, the rationale and any enhancements you select, since an assessor will check that the selection matches the risk documented for the system.

How an assessor tests IA-13 with examine, interview and test methods

This table compares the three SP 800-53A assessment methods for IA-13 against the objects an assessor would pick up, the evidence to prepare and the findings that usually come up. Read each row as one question the assessor asks, then check whether your records answer it. The main takeaway is that an identity provider nobody documented fails the examine step before any technical test begins.

Method	Objects the assessor picks up	Evidence to prepare	Common findings
Examine: policy and procedures	Identification and authentication policy, procedures for user and device identification and authentication, and the defined rules for identity providers and authorization servers	Approved policy naming the authoritative identity providers, owner, review date and the entities covered (users, devices, non-person entities)	Policy covers user logins but says nothing about device or service identities, or the procedure has no named owner
Examine: system security plan	Plan entries describing each identity provider, authorization server and the systems that rely on them	Current SSP section listing every identity source, token flow and the components that consume its assertions	Applications sign in through a local account store that the plan never mentions
Examine: system design documentation	Architecture diagrams showing how identities, attributes and access rights move between the identity provider and each application	Data flow diagrams, attribute mapping tables and a record of which applications trust which issuers	Diagrams are out of date after a platform was added, so attribute sources and trust relationships are unclear
Examine: configuration settings	Identity provider and authorization server settings, including signing keys, token lifetimes, redirect rules and key rotation schedules	Exported configuration files or screenshots with dates, key rotation logs and change tickets for security-relevant settings	Signing keys never rotated, or wildcard redirect URIs left in production
Interview: personnel with operations responsibilities	Administrators, identity engineers and application owners who run or depend on the identity services	Named roles and responsibilities, a record of who approves access rights changes and how those people describe the process	Staff describe the process differently from the written procedure, or no one knows who can revoke a token
Test: identity mechanisms	The identity provider and authorization server in operation, including sign-in, token issuance, token validation and access rights enforcement	Test results showing that an assertion or token is verified by the relying application, that expired or revoked tokens are refused, and that access follows the defined rights	Relying applications accept tokens without checking the issuer, audience or expiry
Test: access rights and attribute accuracy	Attributes and group memberships used for authorization decisions, compared with the authoritative source	Sample reconciliation between the directory and the authorization server, plus a record of the most recent access rights review	No access rights review has been performed, so stale group memberships still grant access
Test: key protection and token management	Storage of signing and encryption keys, token revocation paths and session termination behavior	Key custody records, a documented revocation procedure and test evidence that revoked tokens stop working	Signing keys stored in plain configuration files or readable by more accounts than the policy allows

What evidence passes IA-13 in an assessment

An assessor testing IA-13 will look for a documented policy, a system design that shows where identity providers and authorization servers sit, configuration exports, and test results that prove the mechanisms work. Each artifact below should be produced from the live environment and refreshed on a schedule so it still matches the system at assessment time.

Identity and access policy and procedures

The written policy defines which identity providers and authorization servers the organization uses, which entity types they manage (users, devices and non-person entities), and who approves changes to attributes and access rights. Assessors compare the procedures against what administrators actually do, so the document should name the roles that run each step. Confirm the owner, the approval record and the review date are on the cover page. Review it at least once a year and after any change to the identity platform.

System security plan and identity flow diagrams

The system security plan entry for IA-13 should state the identity providers and authorization servers in scope and show how they connect to applications, directories and administrative consoles. A diagram of each sign-in and token flow lets an assessor trace a request from the user or service to the access decision. Keep the diagram tied to the current configuration, and record each change to a trust relationship in the plan's change history.

Identity provider and authorization server configuration exports

Configuration exports from the identity provider show the protocols enabled, signing and encryption key references, token lifetimes, redirect URI rules and the directories or sources connected to it. Export them from the running system on a fixed cadence and store them under version control so differences are visible. Check that exports never contain plaintext secrets, since the assessor will treat exposed key material as a finding.

Registered applications and non-person entity inventory

A register of every application, service account and automated client that relies on the identity provider, with a named owner, the protocol used and the access rights granted, gives the assessor a population to sample. Non-person entities are often missed, so reconcile this list against token issuance logs and service configurations. Ask the owner to confirm each entry quarterly, and remove clients whose owners cannot be identified.

Attribute source mappings

Attribute mappings show which directory fields, HR records or other authoritative sources populate the claims and roles that drive authorization decisions. An assessor will check that each mapping has an owner and that changes to a source are reviewed before they reach access decisions. Export the mappings with the configuration and note the source system for each attribute. Re-verify them after directory schema changes or onboarding of a new source.

Token validation and key handling test records

Test records should show that tokens are rejected when signatures, issuers, audiences or expiry checks fail, and that signing keys are rotated and retired as documented. Keep the test scripts, the dated results and the ticket for each failed case. Where keys are held in a secrets engine, record the rotation events and who authorized them. Rerun these tests after every upgrade of the identity platform and at the frequency stated in the plan.

How to implement IA-13 in order

This sequence takes IA-13 from a scoping decision to recurring evidence, so that identity providers and authorization servers have a documented policy, configured mechanisms, tested token behavior and an evidence trail an assessor can follow.

Confirm scope and baseline placement
Start by confirming that the system falls under SP 800-53 and deciding whether IA-13 belongs in the control set. SP 800-53B Release 5.2.0 does not select IA-13 for the low, moderate, high or privacy baselines, so the organization must add it by tailoring a baseline or through an overlay. The system owner and the authorizing official record the decision, the rationale and the affected system boundary. Done means a signed tailoring entry exists and the system security and privacy plan references IA-13 with its enhancements. Confirm the tailoring approach with your authorizing body or assessor before you proceed.
Inventory identities and identity sources
Build a register of every identity source in scope: human user directories, device identities, and non-person entities such as service accounts, workloads, automation and API clients. Record which systems issue identities, which systems consume them, and which attributes each one carries. The security engineering team owns the inventory, and the platform team validates it against running systems. Done means each identity population has a named authoritative source and a named consumer list, and gaps are logged as open items in the plan of action and milestones.
Define the identity policy and mechanisms
Write the policy and procedures that govern how identity providers and authorization servers are selected, configured, changed and retired. The document should name the approved providers, the protocols each application may use, the owner of each provider, and the mechanisms for user, device and non-person entity identities. Assessors examine this policy against the IA-13 determination statements, so the wording must match the mechanisms you actually run. Done means the policy is approved, distributed to operators, and cross-referenced to the IA family policy in IA-1.
Configure identity providers and authorization servers
Deploy the identity providers and authorization servers inside your own infrastructure and connect applications to them. For example, an illustrative deployment could use authentik as an identity provider for applications through OAuth2, OpenID Connect, SAML or proxy providers, with FreeIPA supplying single sign-on for Linux and UNIX hosts through an MIT Kerberos KDC. Confirm each protocol and feature against the vendor documentation for your version. Done means each application is registered to a named provider, and the configuration export is stored as a system configuration artifact.
Map attributes and access rights to decisions
Document which attributes the identity provider asserts (group membership, role, device posture or service identity) and how the application or authorization server turns those attributes into access decisions. Remove attributes that are not needed for a decision. This step produces an attribute and access-rights map that ties each entitlement to an owner and an approval record. Done means a sample of decisions can be traced from the asserted attribute to the granted right, and the map is reviewed on the cadence set in the policy.
Protect keys and set token parameters
This step covers the key protection enhancement. Signing keys for assertions and tokens, client secrets and encryption keys for sensitive identity data need controlled storage, rotation and access limits. Where you need application-level encryption for identity-related data, OpenBao's transit secrets engine can encrypt and decrypt data without storing it, sign and verify data, and rotate versioned keys. Nextcloud server-side encryption keeps keys on the server but does not encrypt file names or folder structure, so document that limit if Nextcloud is in scope. Set token lifetimes and signing algorithms in the provider configuration. Done means key custody, rotation and token settings are written down and reflected in configuration exports.
Test token verification and revocation
Cover the assertion and token verification enhancement by testing that relying applications reject expired, altered, wrongly audienced or wrongly signed assertions and tokens. Then test the token management enhancement by revoking sessions and tokens and confirming that access stops within the behavior you documented. Record each test with its input, expected result, actual result and tester. Testing should be performed by someone independent of the configuration owner where possible. Done means test records exist for each verification and revocation case, and any failures have tracked remediation.
Set up recurring evidence capture
Schedule the collection of evidence that an assessor will examine and interview against: current policy, configuration exports, attribute maps, key rotation logs, token test results, access reviews and provider audit logs. Assign an owner for each artifact and a retention location. Ask your assessor which artifact formats they accept before you automate collection. Done means a repeatable evidence package exists for IA-13, and the next assessment cycle can start from it rather than from a rebuild.

How authentik, FreeIPA, OpenBao and Nextcloud support IA-13 evidence

IA-13 asks for identity providers and authorization servers that make authentication and authorization decisions. The four tools below cover different parts of that job: application sign-in, Linux and UNIX single sign-on, key and data protection, and file encryption at rest. None of them makes an organization compliant on its own, and the organization still owns the policy and the control.

authentik as application identity provider

authentik is an identity provider that applications can delegate sign-in to. Its provider types include OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so one identity source can serve web applications, legacy directories and network access. For IA-13 evidence, record which applications are bound to which provider, how user and group attributes are passed to each application, and who can change those bindings. Confirm that the protocols you need and the logging you will rely on meet your own requirements before you cite them.

FreeIPA single sign-on for Linux

FreeIPA provides single sign-on for Linux and UNIX environments, using an MIT Kerberos key distribution center as its authentication core. It fits where IA-13 concerns host and service identities, such as user accounts, host principals and service principals across a Linux estate. Evidence typically includes the realm configuration, the list of enrolled hosts and services, and records of who administers identities. Confirm that Kerberos-based single sign-on works for every platform in your scope, since non-Linux systems and some applications may need a different path.

OpenBao transit engine for keys

The OpenBao transit secrets engine encrypts and decrypts application data without storing that data in the engine. It also signs and verifies data and supports versioned encryption keys with key rotation. These functions bear on the key protection and token verification themes in IA-13, because signing keys and verification steps are what make tokens and assertions trustworthy. Evidence includes key version history, rotation records and the policies that limit who can use each key. Confirm the key rotation schedule and the operational procedures your assessor will expect, since the engine does not set them for you.

Nextcloud server-side encryption limits

Nextcloud server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, which means metadata can remain visible to anyone who reaches the storage. For IA-13 work, this matters when files are tied to identity-based access decisions, because the file tree can reveal sensitive structure even when contents are protected. Document the encryption setting for each storage location, state the metadata exposure in the system security plan, and confirm with your assessor whether that gap is acceptable for your data.

What meeting IA-13 costs in money and effort

This table breaks the cost of meeting IA-13 into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. NIST does not estimate compliance costs, so use the table to shape a quote request rather than to read off a number.

Cost component	Who is paid	One-time or recurring	Main cost drivers
Identity platform licenses or self-hosting	Software vendor if licensed; internal or partner staff if self-hosted	Licenses recur; self-hosting infrastructure recurs	Number of users and applications, high availability design, hosting footprint
Provider and token configuration engineering	Implementation partner or internal engineers	One-time, with periodic changes	Number of applications, protocols in use (OIDC, SAML, LDAP, RADIUS, proxy), custom claims and attribute mappings
Non-person entity onboarding	Internal platform or DevOps team	Initial build, then recurring as services change	Count of service accounts, workloads and devices that need identities and credential rotation
Attribute sources and federation partners	Internal identity team, partner integration engineers	One-time per source, plus recurring maintenance	Number of directories, HR systems, external partners and trust agreements to maintain
Key management setup for signing and encryption	Internal security engineering, or partner for secrets platform design	One-time build, recurring rotation and custody tasks	Key types, rotation frequency, whether keys sit in an HSM or software-backed secrets engine
Evidence upkeep	Internal compliance and security staff	Recurring	Frequency of access reviews, configuration exports, logs retained for assessors, changes to policy
External testing or review of identity flows	Independent testing firm or assessor, if engaged	Recurring per test cycle	Scope of flows tested (login, token issuance, token verification, revocation), number of applications, retest needs
Auditor or assessor sampling	Independent assessor or auditor	Recurring per assessment cycle	Number of identity systems in scope, sample sizes, quality of existing evidence

Who owns IA-13, who prepares the evidence and who assesses it

Your organization owns IA-13. The control asks you to employ identity providers and authorization servers under a defined policy and mechanisms, so the decisions about who or what is an identity, which attributes matter, and who gets which access rights must be made and recorded by your people. No partner or assessor can make those decisions for you, and an assessor will look for evidence that your staff set and reviewed them.

Policy and scope: Own the identification and authentication policy that defines which identity providers and authorization servers are in scope and which user, device and non-person entity populations they serve.
Identity architecture: Decide which systems delegate sign-in to which provider, where authoritative attributes come from, and how token lifetimes and key handling are set.
Access decisions: Approve who may administer the identity provider, who may grant application access and how privileged identities are separated.
Risk acceptance: Record any deviations, exceptions and residual risk in the system security plan and plan of action and milestones, signed by the accountable official.
Ongoing operation: Review logs, access reviews and key rotation results on a schedule you define.

Confirm internally who is accountable for each of these items before you sign a statement of work, because a partner can only prepare what your owners have already decided.

Where IA-13 programs usually fall short and how to close each gap

IA-13 asks for identity providers and authorization servers to be governed under a defined policy and mechanisms, so the gaps that matter most sit at the edges: identities nobody owns, token settings nobody documented, attributes nobody can trace, and applications that sign users in by their own means. Each card below names one gap, the action that closes it and the evidence an assessor can examine or test.

Non-person entities without an owner

Service accounts, API clients, automation bots and workload identities often exist in the identity provider without an inventory record, an accountable owner or a documented purpose. IA-13 covers non-person entities explicitly, so an unowned client is a finding even when its credentials are strong. Close the gap by exporting every service client and account from the identity provider, matching each one to a named owner and a business purpose, and removing or disabling entries that match no owner. Evidence is the reconciled inventory, the owner sign-off and a dated record of removals.

Token lifetimes and key rotation undocumented

Authorization servers often run on default token lifetimes, signing keys and refresh behavior that nobody has written down or approved. An assessor testing IA-13 will ask who set these values, what they are, and how signing keys are rotated and retired. Close the gap by recording access token, refresh token and session lifetimes per client type, the signing key rotation interval and the procedure for emergency revocation, then approving the record under the identity policy. Evidence is the approved configuration baseline, the exported server settings that match it and the rotation log.

Access attributes without a documented source

Group memberships, roles, department codes and clearance flags feed authorization decisions, yet many programs cannot say which system is the authoritative source for each attribute or how changes reach the identity provider. Stale or copied attributes can grant access that no current employee should hold. Close the gap by listing each attribute used in an access decision, naming its authoritative source, the sync method and the update frequency, and testing one change end to end. Evidence is the attribute register, the sync configuration and a test record showing a removed role no longer grants access.

Applications that bypass the central provider

Legacy applications, local administrator accounts and vendor tools sometimes keep their own user stores or accept local passwords, so sign-in decisions happen outside the identity provider. IA-13 depends on the central provider being the decision point for the systems in scope. Close the gap by inventorying every application in the system boundary, classifying each as federated, proxied or exempt with a documented reason, and moving exempt applications onto federation or placing them behind a proxy provider where feasible. Evidence is the application inventory, the federation status per application and the approved exception list with review dates.

Token verification never tested

Teams often confirm that sign-in works but never test whether resource servers reject expired, tampered, wrong-audience or revoked tokens. The IA-13 enhancements on assertion and token verification and on token management call for these checks to be designed and performed. Close the gap by writing test cases for signature validation, expiry, audience and issuer checks, revocation and replay, running them against each protected application and recording the results. Evidence is the test plan, the captured request and response results and the defect tickets raised for any token the application accepted incorrectly.

Policy that omits the identity mechanisms

Identity policies frequently state principles such as least privilege or single sign-on without naming the identity provider, authorization server, token formats, key custody or non-person entity handling. An assessor comparing the policy with the system security plan will find the gap quickly. Close the gap by revising the policy and its procedures to name each identity provider and authorization server in scope, the token and assertion mechanisms in use, where signing keys are held and who approves changes to them. Evidence is the approved policy version, the matching procedures and the system security plan entries that cite them.

What buyers ask about IA-13 cost, effort and outside help

Is IA-13 required by default in NIST SP 800-53?

No. IA-13 is not selected in any SP 800-53B baseline (low, moderate, high or privacy), so it applies only when your organization, a contract or an overlay adds it. In practice, the requirement usually comes from a tailoring decision documented in your system security and privacy plan, or from an agency or customer that asks for it by name. Confirm with the authorizing official or contract owner which baseline applies to your system and whether IA-13 or any of its three enhancements appear in the agreed control set before you plan any work. Adding the control later is a tailoring change, so record the rationale when you make it.

How much effort does IA-13 add to an existing identity program?

The effort depends on how much of your identity architecture already exists. An organization that already runs a central identity provider for its applications has less to add than one where each application keeps its own user store. The work usually falls into three parts: documenting which identity provider and authorization server are authoritative, showing how user, device and non-person identities and their attributes feed access decisions, and producing evidence for the key protection, assertion and token verification and token management enhancements if you select them. No supplied figure sizes this work, so ask any partner for a scope that lists each system, identity source and enhancement, and the hours or phases they assign to each.

What does the internal team need to provide?

Your team owns the control. Expect to provide:

A named owner for the identity provider and authorization server configuration
Access to the application inventory, directory sources and service account lists
Decisions on policy, attribute sources and token lifetimes, which the assessor will check against your documented procedures
Change approval for production identity changes and staff time for interviews

Because assessors interview personnel with system operations responsibilities, the people who run the identity platform must be available during the assessment window.

Can our team implement IA-13 without outside help?

Yes, if you have engineers who have built and operated an identity provider, an authorization server and a secrets or key management service, and if someone can own the written evidence. Outside help is most useful when the team lacks that experience, when many systems must be brought under one identity design, or when an assessor expects a tested, documented evidence package on a fixed date. Weigh the cost of a partner against the cost of delay and rework. A partner can prepare systems and evidence, but your organization keeps accountability for the controls.

What drives the timeline for an IA-13 engagement?

The main drivers are the number of identity sources, the number of applications that must delegate sign-in, whether non-person entities such as services and devices are in scope, and how much existing documentation must be rewritten. Change windows, procurement approvals and the assessor's schedule also set the pace. Organizations that already have an identity provider and clear policy usually move faster than those that must first agree on a single source of truth. Ask for a schedule with milestones tied to specific deliverables, not calendar estimates, and confirm which dependencies sit outside the engagement.

Can an implementation partner issue the IA-13 assessment result?

No. An implementation partner such as DeployOpen prepares systems, configurations and evidence for an assessment, but it does not issue assessment reports, attestations or certifications. The assessment result comes from the assessor or authorizing body your contract or agency names, working under the rules that apply to your program. Before you sign anything, confirm who the assessor will be, what report they issue, and how they will receive your evidence. Keep the roles separate in the statement of work so no one assumes the partner is the source of the outcome.

What should a written scope for IA-13 include?

A written scope should name the following:

The systems, identity providers, authorization servers and applications covered
Which IA-13 enhancements are in scope, and the reason for each
The user, device and non-person entity populations, and their attribute sources
Deliverables such as configuration records, policies, test results and an evidence index mapped to the assessment procedures
The assessor and report owner, plus each party's responsibilities
Assumptions, exclusions, change control and the acceptance criteria

Ask for a fixed-scope quote built from this document. DeployOpen does not publish a price list, so the quote follows from the written scope.

How DeployOpen scopes and prepares IA-13 evidence

DeployOpen plans and implements self-hosted open-source identity providers and authorization servers inside the client's own infrastructure, then prepares the configuration and records an assessor would examine for IA-13. The organization owns its identity policy and control decisions, and only an independent assessor issues assessment results.

How we scope

Agree in writing which identity providers, authorization servers and non-person entity types fall under IA-13.
Record the organization's IA-13 policy, mechanisms and the applications that will delegate sign-in.
Define which key protection, token verification and token management enhancements the organization chooses to adopt.
Confirm the fixed scope, deliverables and timeline in writing before any work starts.

How we build

Deploy the chosen identity provider, such as authentik, within the client's cloud, data center or air-gapped network.
Configure OAuth2, OpenID Connect or SAML providers so applications delegate authentication and authorization decisions.
Set up signing and encryption key handling, including versioned keys and rotation, using the client's approved key management.
Test token issuance, verification and revocation against the configuration the organization documented.

How we hand over

Deliver system configuration exports and design documentation that show how identities, attributes and access rights are managed.
Provide test records for assertion and token verification, mapped to the four IA-13 determination statements in SP 800-53A.
Document the interfaces, owners and procedures so an assessor can interview the operations staff responsible.
Transfer administration knowledge to the client's team and confirm the handover in writing.

How we support

Offer ongoing support, upgrades and continuous testing of the identity platform as a retainer.
Refresh configuration evidence when applications, providers or key policies change.
Re-run token and key protection tests after upgrades so the evidence stays current for the next assessment.
Let the organization's independent assessor review the evidence; DeployOpen does not issue reports or certifications.