{"description":"Monthly authentication-platform operating cycle. Anchor: this instance runs on the existing Process item for authentication-platform / session-management operations (process_type: security_process, frequency: monthly) — enrich that standing Process each cycle, never create a duplicate — with the four operated Control items UC-ACCESS-09/11/12/13 (framework tags carrying the standards mapping, domains: access_control_identity) linked to it. In scope: MFA enforcement and enrollment across remote, privileged, and sensitive-data access; secure log-on and federation-trust verification; lockout and anomalous-logon defense; session lifecycle controls (inactivity lock, automatic termination, concurrent-session limits, re-authentication for sensitive operations); and system-use, last-logon, and failed-attempt notices, across the IdP or SSO tenant, VPN or remote-access gateway, PAM tooling, and applications classified as housing sensitive data. Out of scope: identity provisioning and joiner-mover-leaver lifecycle, access certification, and privileged-access request approval, which are operated by their own workflows. There is no upstream workflow dependency: the instance is self-originating on its own initial inputs — the authentication-platform inventory (a document on the anchor Process, refreshed each cycle) and the prior-cycle operating record (the prior Workflow instance on the same Process plus its carried-forward open Issue items). The four operating areas run in parallel and reconverge at the platform-posture disposition. Named deliverables: the MFA enforcement-coverage register, the authentication-posture memo, the lockout-and-anomaly log, the session-policy compliance matrix, the banner-and-notice verification record, the platform-health dashboard and readiness summary, and the corrective-action register — each attached to its step, with every gap raised as a self_assessment Issue linked to the Control it degrades. There is no downstream handoff: this terminal recurring cycle seeds its own successor via carry-forward Issue items at close.","edges":[{"id":"e-assess-authentication-posture-remediate-authentication-gaps","label":"Gaps","source":"assess-authentication-posture","target":"remediate-authentication-gaps","whenValue":"gaps_identified"},{"id":"e-assess-authentication-posture-classify-platform-posture","label":"Sound","source":"assess-authentication-posture","target":"classify-platform-posture","whenValue":"posture_sound"},{"id":"e-remediate-authentication-gaps-classify-platform-posture","source":"remediate-authentication-gaps","target":"classify-platform-posture"},{"id":"e-classify-platform-posture-log-corrective-actions","label":"Gaps","source":"classify-platform-posture","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-classify-platform-posture-close-and-archive","label":"Healthy","source":"classify-platform-posture","target":"close-and-archive","whenValue":"healthy"},{"id":"e-log-corrective-actions-close-and-archive","source":"log-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-09","UC-ACCESS-11","UC-ACCESS-12","UC-ACCESS-13"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-authentication-platform-session-policy-operations","contentDigest":"sha256:a423b169a8e3d6d6864e185744540fef3107b5e5c468eb937fccef9fff160210","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:a423b169a8e3d6d6864e185744540fef3107b5e5c468eb937fccef9fff160210","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-authentication-platform-session-policy-operations"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-authentication-platform-session-policy-operations","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2","iso-27001","nydfs-500"],"teams":["it"]},"name":"Authentication Platform & Session Policy Operations","nodes":[{"data":{"decisionField":"authentication_posture","description":"Agent verifies unique user identification, live MFA enforcement and enrollment across the remote, privileged and sensitive-data populations, protected log-on channels, signed and verified federation assertions, and external-user rigor; human decides whether authentication posture is sound or needs remediation","formData":{"fields":[{"key":"authentication_posture","label":"Authentication Posture","options":[{"label":"Posture sound, no gaps","value":"posture_sound"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Establish the cycle's authentication evidence — unique identification, live MFA enforcement and enrollment across the remote, privileged, and sensitive-data populations, protected log-on channels, federation-assertion trust, and external-user rigor — and decide whether the authentication area is sound or must be remediated before the cycle's platform posture is judged. Owned by the IAM platform engineer; resolves the decisionField `authentication_posture`.\n\n**Inputs**\n- The authentication-platform inventory and scope for this monthly cycle: the IdP or SSO tenant, the VPN or remote-access gateway, PAM (privileged-access) tooling, and the register of applications classified as housing sensitive data. This lives as a document attached to the anchor Process item (process_type: security_process), refreshed each cycle, with the scope statement in Process.description. This is a parallel entry point — it runs on the cycle's own initial inputs, not another checkpoint's output; there is no upstream workflow to consume.\n- The identity platform's account roster per population (remote, privileged, sensitive-data) and the live conditional-access or authentication-policy engine rules — these stay in the external IdP/PAM system and are pulled live via coach-query-data; the AssureSwarm copy is the roster extract inside the enforcement-coverage register attached to this step.\n- Log-on endpoint, load-balancer, and gateway configuration; the federation and SSO configuration for every relying party; and the external / non-organizational user population.\n- The prior-cycle operating record — the prior Workflow instance on the same anchor Process (its exported operating record) — plus any open MFA corrective actions carried forward as Issue items linked to the anchor Process and its Control items.\n- The governing control standards: the UC-ACCESS-09 Control item in the control library (control_id, framework: nist-800-53 | nist-csf-2 | iso-27001, domains: access_control_identity) mapping NIST 800-53 IA-2, IA-8, IA-11; NIST CSF 2.0 PR.AA-03 and PR.AA-04; ISO 27001 A.8.5.\n\n**Procedure**\n_Items 1–5 are agent-run (folded from the former \"Operate MFA enforcement and enrollment\" step) and items 6–9 assemble the posture memo; the human moment is the branch decision below._\n1. Query the account roster across remote-access, privileged-access (PAM), and sensitive-data populations. Confirm every account is uniquely identified and attributable to one authenticated individual. Flag any shared, generic, service, or unattributed credential in scope — these break individual accountability (IA-2) and are findings even if MFA is present.\n2. Pull the live conditional-access or authentication-policy engine rules and confirm MFA is enforced in production, not in draft, report-only, or audit mode, for each population. A rule that exists but is not in enforce mode is a gap, not a control.\n3. Cross-reference the enforcement rules against each population roster to find enrollment gaps: users in scope for mandatory MFA with no registered authenticator factor, and accounts able to authenticate through a legacy or basic-auth path that bypasses the enforcing rule.\n4. Compute enforcement and enrollment coverage per population (accounts enrolled and enforced divided by accounts in scope). Compare against the mandated threshold, typically 100 percent for privileged and remote access. Any shortfall is a finding. Attach the enforcement-coverage register.\n5. Open a remediation item for each identification, enforcement, or enrollment gap, capturing user or account, population, gap type, root cause, and owner.\n6. Query the log-on endpoint, load-balancer, and gateway configuration and confirm credentials are validated only over protected channels — TLS enforced end to end, with no plaintext or downgraded log-on path reachable from any in-scope network (IA-2, SC-8).\n7. Pull the federation and SSO configuration for every relying party: signing-certificate validity, assertion signature verification, audience and issuer restriction, and assertion expiry. Flag any relying party accepting an unsigned, unprotected, or unverified SAML or OIDC assertion (IA-8).\n8. Pull the external and non-organizational user population (contractors, partners, customer-facing accounts). Confirm each is bound to an authentication policy at the same rigor as internal users and that the assigned authentication strength is documented against the risk of the interaction.\n9. Consolidate items 6–8 with the identification, enforcement and enrollment findings and the enforcement-coverage register from items 1–5 into a single authentication-posture memo.\n\n**Decision criteria**\n- `posture_sound` — choose when protected-channel log-on, signed-and-verified federation assertions, and documented external-user rigor all pass, AND the MFA enforcement and enrollment result is clean (coverage at threshold with no open identification, enforcement, or enrollment gap).\n- `gaps_identified` — choose when any identification, enforcement, enrollment, log-on-channel, federation-trust, or external-user gap remains open.\n\n**Record in AssureSwarm**\n- Submit the `authentication_posture` SELECT field with the chosen value; record the decision rationale and evidence references in the step result and name the decision owner or approver.\n- Item create: an Issue per gap (coach-item-create) — issue_type: deficiency (or exception where the gap is a time-boxed accepted risk), source: self_assessment, issue_owner, identified_date, root_cause, with the population and gap type in description.\n- Item relationship: link each Issue to the UC-ACCESS-09 Control it degrades and to the anchor Process (coach-items-link).\n- Step document: attach the enforcement-coverage register — per-population roster, enforcement mode, enrollment coverage percentage, and threshold — as an XLSX/CSV on this step (coach-document-upload), the AssureSwarm evidence copy of the coach-query-data pulls; attach the authentication-posture memo alongside it.\n\n**Exit criteria** — Every in-scope account confirmed uniquely identified; MFA confirmed live in production for every remote, privileged, and sensitive-data population; enrollment coverage computed against threshold with each shortfall raised as an owned item; the enforcement-coverage register and the authentication-posture memo are attached; the `authentication_posture` form is submitted with rationale and owner; the unused branch is prunable (`posture_sound` skips remediation and drains to the platform-posture join, `gaps_identified` routes to remediation first).","kind":"decision","label":"Assess authentication posture","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"assess-authentication-posture"},{"data":{"description":"Agent closes MFA enforcement, enrollment, log-on-channel, and federation-trust gaps and re-verifies; human confirms every gap is closed before continuing","instructions":"**Objective** — Close every open identification, MFA enforcement, enrollment, log-on-channel, or federation-trust gap flagged at the posture decision so the cycle continues on a sound authentication baseline.\n\n**Inputs**\n- The authentication-posture memo from the assess-authentication-posture decision, listing each gap and its root cause.\n- The MFA enforcement-coverage register.\n- Write access to the conditional-access or authentication-policy engine and to the federation and SSO configuration to push fixes.\n\n**Procedure**\n1. Parse the authentication-posture memo and list each gap with its root cause: unattributed or shared credential, missing or misconfigured enforcement rule, unregistered authenticator factor, unprotected or downgraded log-on path, or unsigned or unverified federation assertion.\n2. Apply the fix per gap: remove or individualize the shared credential; push the corrected conditional-access rule into enforce mode; complete the missing authenticator enrollment; close the downgraded log-on path; or correct the federation signing and verification settings (signature verification, audience and issuer restriction, certificate validity).\n3. Re-query the affected policy, population, and federation configuration to confirm each fix is live in production and actually takes effect for the affected accounts — re-verify, do not assume the change deployed.\n4. Track each fix as an item linked to its originating finding, and record documented residual risk for anything that cannot be fully closed this cycle.\n\n**Record in AssureSwarm**\n- Item field update: on each originating Issue (from the MFA and posture steps), set Issue.remediation_plan, Issue.actual_remediation_date, and Issue.verified_date on re-verification (coach-item-update); capture any residual-risk carve-out that cannot be fully closed this cycle in Issue.management_response.\n- Item relationship: where a fix is tracked as its own item, create it (coach-item-create) and link it to its originating finding Issue (coach-items-link).\n- Step document: attach the remediation log and re-verification evidence to this step (coach-document-upload) — the AssureSwarm evidence copy of the coach-query-data re-verification pulls.\n\n**Exit criteria** — Every authentication gap is verifiably closed in production or carries documented residual risk with a named owner; the remediation log and re-verification evidence are attached.","label":"Remediate authentication gaps","performedBy":{"primitives":["coach-item-update","coach-item-create","coach-items-link","coach-query-data","coach-document-upload"]}},"id":"remediate-authentication-gaps"},{"data":{"decisionField":"platform_posture_disposition","description":"Judge lockout and anomaly tuning, session timeouts and re-authentication, and approved logon notices together with the authentication result.","formData":{"fields":[{"key":"platform_posture_disposition","label":"Platform Posture Disposition","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge lockout and anomaly tuning, session timeouts and re-authentication, and approved logon notices together with the authentication result.\n\n**Inputs**\n- The authentication-platform inventory and scope — a document on the anchor Process item (the cycle's initial input). This is a parallel entry point: it runs independently of the MFA, session, and notice checkpoints on its own configuration and event data.\n- The live lockout and throttling configuration per authentication surface and the approved policy thresholds — held in the external IdP/SIEM and pulled via coach-query-data; the AssureSwarm copy is the lockout-and-anomaly log attached to this step.\n- Every logged account-lockout event and anomalous-logon signal since the last cycle — these stay in the external SIEM/IdP event stream; the log document captures the triaged extract.\n- The governing control standard: the UC-ACCESS-11 Control item (mapping NIST 800-53 AC-7, IA-10).\n- The authentication-platform inventory and scope — a document on the anchor Process item (the cycle's initial input). This is a parallel entry point: it runs independently of the MFA, lockout, and notice checkpoints.\n- The session-management configuration per platform (IdP, core application, PAM, remote-access gateway) — held in the external systems and pulled via coach-query-data; the AssureSwarm copy is the session-policy compliance matrix attached to this step.\n- The approved session-management standard carrying the session-policy values (timeouts, concurrent-session cap, re-authentication interval) — held on a Policy item (policy_type: standard, policy_owner, review_frequency: annual, framework: nist-800-53 | nist-csf-2 | iso-27001, domains: access_control_identity), with the values document attached to that Policy and the Policy linked to the UC-ACCESS-12 Control it governs.\n- The governing control standard: the UC-ACCESS-12 Control item (mapping NIST 800-53 AC-11, AC-12, AC-10, IA-11).\n- The authentication-platform inventory and scope — a document on the anchor Process item (the cycle's initial input). This is a parallel entry point: it runs independently of the MFA, lockout, and session checkpoints.\n- The log-on page configuration per in-scope platform — held in the external systems and pulled via coach-query-data; the AssureSwarm copy is the banner-and-notice verification record attached to this step.\n- The current approved, legal-reviewed system-use notification standard — held on a Policy item (policy_type: standard, policy_owner, approved_by, review_frequency: annual with next_review_date, framework: nist-800-53, domains: access_control_identity), with the legal-reviewed banner text document attached to that Policy and the Policy linked to the UC-ACCESS-13 Control it governs.\n- A sample of recent successful logons across in-scope platforms — drawn from the external logon record.\n- The governing control standard: the UC-ACCESS-13 Control item (mapping NIST 800-53 AC-8, AC-9).\n\n**Procedure**\n_This checkpoint absorbs “Operate lockout and anomaly defense”, “Operate session lifecycle controls”, “Verify logon banners and notices”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Operate lockout and anomaly defense: Query the live lockout and throttling configuration across every authentication surface — the failed-attempt threshold and the lockout duration or administrator-release requirement — and confirm each matches the approved policy value (AC-7: lock after N consecutive failed attempts).\n2. Pull every logged account-lockout event and every anomalous-logon signal (impossible travel, new device, unrecognized location or behavior) since the last cycle.\n3. Triage each event: confirm the lockout correctly fired at the threshold, or determine why a risk signal did not trigger the expected adaptive response.\n4. Open a triage record for each unresolved or miscalibrated event — a threshold set too loose, a risk signal that should have forced step-up authentication, additional verification, or denial but did not, or a legitimate user repeatedly locked out — and link it to the source event.\n5. Tune the risk-based step-up rules per the triage findings and record the tuning rationale so a reviewer can see why each adjustment was made.\n6. Operate session lifecycle controls: Query the session-management configuration across every in-scope platform for the inactivity-lock timeout and the pattern-hiding lock display (AC-11); confirm the locked session requires re-authentication to resume rather than a simple dismiss.\n7. Confirm each platform's automatic-termination condition actually ends the session on extended inactivity rather than leaving it locked indefinitely (AC-12), and pull the concurrent-session limit enforced per account (AC-10).\n8. Compare each platform's live settings against the approved policy values and flag any platform running a longer timeout, a lock screen that does not hide content, no automatic termination, or no concurrent-session cap.\n9. Confirm re-authentication is actually required, not merely recommended, before sensitive operations, privilege changes, or after the defined interval (IA-11), by sampling recent sensitive-operation events and checking each carries a fresh authentication.\n10. Open a remediation item for each platform out of tolerance, capturing the platform, the setting, the approved value, and the observed value.\n11. Verify logon banners and notices: Query the log-on page configuration for every in-scope platform and confirm the current approved system-use notification — stating monitoring, usage terms, and privacy expectations — renders before credential entry (AC-8), and where acknowledgment is mandated, that the acknowledgment is actually captured and stored.\n12. Diff the deployed banner text against the current approved, legal-reviewed version and flag any platform serving a stale, modified, or missing banner.\n13. Sample recent successful logons across in-scope platforms and confirm the last-logon date and time, and the failed-attempt count where the platform supports it, actually display to the user immediately after authentication (AC-9), so a user can detect unauthorized use of their account.\n14. Open a remediation item for any platform with a stale banner, missing acknowledgment capture, or missing last-logon or failed-attempt notice.\n\n**Decision criteria**\nThe agent first assembles the cross-area evidence:\n1. Compute the cycle metrics: MFA enforcement and enrollment coverage; authentication-posture remediation closure; lockout and anomaly triage completion; session-policy compliance rate; and banner-and-notice verification results.\n2. Build a platform-health dashboard showing each metric against its threshold and the trend against prior cycles.\n3. List every open item across all four control areas with its owner and evidence reference, and draft a readiness summary.\n\nThen select the branch:\n- `healthy` — choose when every metric across MFA, lockout and anomaly defense, session controls, and notifications is within tolerance and no open item remains in any control area.\n- `gaps_identified` — choose when any open item remains in any control area, or any metric is below threshold.\n\n**Record in AssureSwarm**\n- Item create: an Issue per unresolved or miscalibrated event (coach-item-create) — issue_type: observation (or exception where a loose threshold is temporarily accepted), source: self_assessment, issue_owner, identified_date, root_cause, with the source event reference in description.\n- Item relationship: link each Issue to the UC-ACCESS-11 Control and to the anchor Process (coach-items-link) — the raw source event stays in the external SIEM, referenced by id in the log.\n- Step document: attach the lockout-and-anomaly log together with the tuning record as an XLSX/CSV on this step (coach-document-upload) — the AssureSwarm evidence copy of the coach-query-data pulls.\n- Item create: an Issue per out-of-tolerance platform (coach-item-create) — issue_type: deficiency, source: self_assessment, issue_owner, identified_date, root_cause, with the platform, setting, approved value, and observed value in description.\n- Item relationship: link each Issue to the UC-ACCESS-12 Control and to the anchor Process (coach-items-link).\n- Step document: attach the session-policy compliance matrix as an XLSX on this step (coach-document-upload) — the AssureSwarm evidence copy of the coach-query-data pulls.\n- Item create: an Issue per gap (coach-item-create) — issue_type: deficiency, source: self_assessment, issue_owner, identified_date, root_cause, naming the stale banner, missing acknowledgment capture, or missing last-logon/failed-attempt notice in description.\n- Item relationship: link each Issue to the UC-ACCESS-13 Control and to the anchor Process (coach-items-link).\n- Step document: attach the banner-and-notice verification record on this step (coach-document-upload) — the AssureSwarm evidence copy of the coach-query-data pulls.\n- Submit the `platform_posture_disposition` SELECT field with the chosen value.\n- Record the decision rationale and evidence references in the step result and name the decision owner or approver.\n- Attach the readiness summary and build the platform-health dashboard (coach-dashboard-create, coach-document-upload).\n\n**Exit criteria**\n- Lockout and throttling confirmed at the approved threshold on every surface; every logged lockout and anomalous-logon event triaged; the risk-based step-up tuning is justified and recorded before it is applied.\n- Every in-scope platform confirmed enforcing the inactivity lock with re-authentication to resume, automatic termination, concurrent-session limits, and re-authentication for sensitive operations and privilege changes; out-of-tolerance platforms raised as owned items; the compliance matrix is attached.\n- The approved system-use notification confirmed live everywhere it is required; last-logon and failed-attempt notices confirmed reaching users; every gap raised as an owned item; the verification record is attached.\n- The `platform_posture_disposition` form is submitted with rationale and owner; the dashboard and readiness summary are attached; the unused branch is prunable (`healthy` routes straight to closure, `gaps_identified` routes to corrective-action logging first).","kind":"decision","label":"Classify platform posture","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-dashboard-create"]}},"id":"classify-platform-posture"},{"data":{"description":"Agent converts each identified gap into an owned corrective action; human confirms every gap is owned and dated","instructions":"**Objective** — Convert every gap identified at the platform-posture review into an owned, dated, tracked corrective action so nothing degrades the authentication platform unaddressed.\n\n**Inputs**\n- The readiness summary and platform-health dashboard from the classify-platform-posture decision.\n- The open-item list across all four control areas with owners and evidence references.\n\n**Procedure**\n1. Parse the readiness summary and list each gap with its root cause and the control area it belongs to: MFA enforcement and enrollment, lockout and anomaly defense, session lifecycle controls, or logon banners and notices.\n2. Create a corrective-action item for each gap capturing root cause, owner, due date, and interim mitigation, and link it to the driving metric or finding.\n3. Raise a platform-level improvement item for any systemic gap — for example a policy-engine limitation blocking enforcement, or a platform that structurally cannot display last-logon notices — and escalate any control area carrying a repeat finding across cycles.\n4. Confirm every gap has a named owner and a due date before closure.\n\n**Record in AssureSwarm**\n- Item create: an Issue per gap (coach-item-create) — issue_type: deficiency (systemic, cross-cycle repeat escalations as issue_type: significant_deficiency), source: self_assessment, issue_owner, target_remediation_date, root_cause, remediation_plan (with interim mitigation).\n- Item relationship: link each Issue to the driving Control item (UC-ACCESS-09/11/12/13) it belongs to and to the anchor Process (coach-items-link).\n- Step document: attach the corrective-action register as an XLSX on this step (coach-document-upload).\n\n**Exit criteria** — Every gap has a named owner and due date; systemic issues escalated as platform-level items; the corrective-action register is attached; nothing is left untracked.","label":"Log corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-corrective-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The full operating record for this cycle: all checkpoint evidence, both decisions, and (where the gaps branch ran) the corrective-action register.\n- The designated evidence repository and its retention controls.\n- The control execution log and the monthly schedule.\n\n**Procedure**\n1. Export the full operating record and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n2. Create carry-forward items for open corrective actions and upcoming policy-threshold reviews, and link them to their source so they arrive as explicit inputs to the next cycle.\n3. Update the control execution log with the cycle result and key metrics, and confirm the next monthly cycle is scheduled.\n4. Confirm the archived record is immutable and retrievable.\n\n**Record in AssureSwarm**\n- Workflow instance: this run on the anchor Process is the durable monthly operating record; export it as the signed audit trail (coach-workflow-export) and archive it under retention.\n- Item create: carry-forward Issue items for open corrective actions and upcoming policy-threshold reviews (coach-item-create), each linked to its source Issue/Control and to the anchor Process (coach-items-link) — these become the next instance's prior-cycle open-corrective-actions input (this terminal recurring cycle seeds its own successor; there is no downstream handoff package).\n- Step document: attach the closure record (coach-workflow-export output + archive location and reference) on this step (coach-document-upload).\n\n**Exit criteria** — The archived record is confirmed immutable and retrievable; every open item is carried forward with a tracked owner; the control execution log is updated and the next cycle is scheduled; the authorized cycle record is complete.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-authentication-platform-session-policy-operations"}