> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/request-management/secret-codes.md).

# Secret codes

Some identity actions hand a locked-out employee a password, an access code or a recovery key. Siit delivers that value privately, shows everyone else only that a code was issued, and takes it back wh

A few actions produce a value that only one person should ever read: a temporary password, an Okta temporary access code, a Microsoft Entra Temporary Access Pass, a Google backup verification code, the FileVault or BitLocker recovery key of a computer. Siit calls those **secret codes** and handles them differently from every other action result.

The code goes to the employee it belongs to, through a private channel. Nobody else sees it — not the request thread, not the AI agent, not the workflow history, not an export. Everyone else sees an event saying a code was issued, who it went to, and when it expires.

### Actions that issue a code

| Action                               | Integration                       | What the employee gets                                                         |
| ------------------------------------ | --------------------------------- | ------------------------------------------------------------------------------ |
| **Set a temporary password**         | Google Workspace, Microsoft Entra | A password, generated by Siit or typed by you, to change at their next sign-in |
| **Generate temporary password**      | JumpCloud                         | A password Siit generates, which must be changed at next sign-in               |
| **Issue a temporary access pass**    | Microsoft Entra                   | A single-use pass that signs them in once so they can register a new method    |
| **Create temporary access code**     | Okta                              | A single-use code that lets them enrol a new authenticator                     |
| **Issue a backup verification code** | Google Workspace                  | One backup verification code, to pass the second step after their password     |
| **Recovery Key**                     | JumpCloud, Jamf, Iru              | The FileVault or BitLocker key escrowed for their computer                     |
| **Recovery Key**                     | Intune                            | The BitLocker key of their computer's operating system volume                  |
| **Recovery Lock Password**           | Jamf, Iru                         | The Recovery Lock password of their Apple silicon Mac                          |

Each one runs from the request side panel and from the person or equipment page. All except Intune's **Recovery Key** also run from a workflow and from an IT Agent playbook. Like every integration action, it can be gated behind an approval, and the role running it needs the integration under **External actions** — see [Roles & permissions](/workspace/roles-and-permissions.md).

Two of them only run on a workflow whose trigger is a request: **Issue a temporary access pass** and **Issue a backup verification code**.

**Invalidate backup verification codes** is the companion to Google's backup code. It produces no secret, so it runs anywhere the other Google actions do. Run it once the employee has enrolled a new phone or security key, so the code you handed them stops working.

For device secrets, not every provider offers every surface:

| Provider     | Secrets                              | Request, person and equipment pages | IT Agent and workflows |
| ------------ | ------------------------------------ | ----------------------------------- | ---------------------- |
| JumpCloud    | Recovery Key                         | Yes                                 | Yes                    |
| Iru (Kandji) | Recovery Key, Recovery Lock Password | Yes                                 | Yes                    |
| Jamf         | Recovery Key, Recovery Lock Password | Yes                                 | Yes                    |
| Intune       | Recovery Key                         | Yes                                 | No                     |

Intune reads the BitLocker key as the admin who is signed in, so it is offered on the pages you open yourself and not to an agent or a workflow, which have nobody to sign in as.

{% hint style="info" %}
A device secret is **fetched, not generated**. The MDM holds it and nothing rotates it, so it stays valid until IT rotates it on the computer. It is offered only on a computer that has that secret escrowed and that Siit holds for that employee. Sending it to them also needs their account to match the computer's owner in the MDM — read live at the moment you run it, so a Mac reassigned an hour ago cannot reach its previous holder.
{% endhint %}

### How the code reaches the employee

Siit picks the private channel the employee already uses.

| Where the request lives     | Where the code goes                                            |
| --------------------------- | -------------------------------------------------------------- |
| Slack                       | A direct message from the Siit app, behind a **Reveal** button |
| Microsoft Teams             | A personal chat, behind a **Reveal** button                    |
| Portal or the admin console | A reply on the request that only the requester can open        |

The **Reveal** button opens the value in a Slack modal or a Teams dialog, so it never enters channel history, an export, or a message event. Only the person the code was issued for can reveal it, and only while it is still valid.

When an agent is talking to an employee in a public channel, Siit sends the code to that person's direct message and the agent says so in the thread. The code itself never appears in the public conversation.

### What everyone else sees

Every issuance writes a **Secret code issued** event on the request feed and on the person's and the computer's timeline. The event names the code, the recipient, where it was delivered and when it expires — never the value.

* A chat delivery reads *sent by Slack direct message, deleted when it expires*.
* A delivery in the request reads *posted on this request for the requester only, hidden when it expires*.
* A code an admin revealed to themselves says neither: nothing expires visibly, because the admin holds it.

The same event reaches the requester's thread and the public thread of the request. It never goes to followers, to admins, or to email.

Fetching a recovery key or a Recovery Lock password through Jamf, Iru or Intune writes these events too.

### Expiry

A code lives for **60 minutes** by default. Siit can set a different lifetime for your workspace, up to a maximum of 24 hours.

When the code expires, Siit takes it back:

* the encrypted value is deleted;
* the Slack or Teams message carrying it is deleted;
* a reply posted on a request is rewritten to `[code expired]`;
* anywhere the code was referenced — agent history included — reads `[code expired]`.

Three cases do not follow your workspace lifetime:

* **Okta temporary access code** — Okta sets its own expiry and that expiry wins, whatever your workspace lifetime says.
* **Microsoft Entra Temporary Access Pass** — Entra sets the pass lifetime from your tenant's authentication methods policy. Siit stops showing the pass at whichever comes first, your workspace lifetime or the pass's own.
* **Google backup verification code** — the code does not expire at all. Siit stops showing it after your workspace lifetime, but the code itself keeps working until it is used or you invalidate the employee's backup codes. Siit says so wherever it hands the code over, and never tells the employee it expires.

### Issuing a code from a request

Open the request, find the integration block in the side panel, and run the action.

For a temporary password — Google Workspace, Microsoft Entra or JumpCloud — you choose between letting Siit generate the password and typing one yourself:

* **Generate a password** — Siit creates the password and sends it to the requester. You can also reveal it once, with a copy button, if you would rather read it out yourself.
* **Type a password** — you supply the password. A password you typed is never shown back to you, and Siit sends it to the requester the same way.

Each provider enforces its own rules on a password you type: Google accepts 8 to 100 characters, Entra asks for 8 to 256 characters with at least three of an uppercase letter, a lowercase letter, a digit and a special character.

For a **temporary access pass** or a **backup verification code**, there is nothing to choose: tick **Send it to the requester privately** or leave it off to read the value once yourself. Neither provider gives the value back afterwards, so copy it before you close the dialog.

If the send to the requester is refused or fails, Siit shows you the code once instead and records that you revealed it. On any other error the code stays where the employee can still reach it and is never shown to you.

For a device secret, the action opens a short dialog where you choose what happens to it:

* **Send it to the requester privately** — the secret goes to them and only them, through their Slack direct message, their Teams personal chat, or a reply on the request only they can read. You never see it.
* leave that off and the secret is **shown to you once**. Copy it before you close the dialog; Siit does not show it again.

A device Siit holds for one person but whose MDM owner is somebody else cannot be sent to the requester. You can still reveal it to yourself, because then you are the recipient.

### Issuing a code from a workflow

A workflow step that issues a code **sends it itself**. There is no separate send action to add after it.

Because of that, the step needs somewhere private to send to:

* it runs on **Request** and **App access** workflows, where there is a requester and a thread;
* **Issue Temporary Access Pass** and **Send Backup Verification Code** run on **Request** workflows only;
* it fails before the provider is ever called when the request has no private channel;
* a **People** workflow has no request to send through, so it does not offer a generated code.

The failure is reported on the workflow run like any other step error, and no code is issued.

A **Set Temporary Password** step asks you the same question as the side panel. Pick **Generated by Siit** for a new random password on every run, sent to the requester privately, or **Typed here** for a fixed password, stored encrypted and never shown again. A typed password can be sent to the requester too.

***

*Related:* [*Google Workspace*](/integrations/iam/google-workspace.md) *·* [*Microsoft Entra ID*](/integrations/iam/microsoft-entra-id.md) *·* [*JumpCloud*](/integrations/iam/jumpcloud.md) *·* [*Okta*](/integrations/iam/okta.md) *·* [*Jamf*](/integrations/mdm/jamf.md) *·* [*Iru*](/integrations/mdm/iru.md) *·* [*Intune*](/integrations/mdm/intune.md) *·* [*Actions library*](/workflow/actions-library.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.siit.io/request-management/secret-codes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.