TL;DR: The service cannot open encrypted PDFs and the API accepts no password parameter, so stop trying to send the locked file. Decrypt it with the owner password into an unlocked working copy, then analyze the copy. Get the password from the document owner - there is no supported workaround without it.

```text
InvalidRequest
```

1. Read the full error body, not just the code.
   Expected: the message mentions the document being password protected or encrypted - that confirms the cause.
2. Get the owner password from whoever produced the contract (your client, the counterparty, your own vault).
   Expected: you have the password; without it there is no path forward.
3. Create an unlocked working copy: run qpdf in decrypt mode with the owner password, writing to a new file.
   Expected: the new file opens without a password prompt.
4. Submit the unlocked copy to Document Intelligence.
   Expected: 202 Accepted and a normal analysis result.
5. Delete or vault the unlocked copy per your retention policy; keep the encrypted original as the record.

## Use this when
- Document Intelligence returns InvalidRequest on a PDF you know is password-protected
- the same code works on every unprotected file
- a password prompt appears when you open the file locally

## Not for this skill when
- the PDF is signed but not encrypted (different failure - see the signed-PDF skill)
- the error body does not mention protection (check file corruption instead)
- you do not have the password and the owner will not share it - the service cannot help you

## Variant phrasings
### azure document intelligence password protected pdf InvalidRequest
### form recognizer encrypted pdf not supported
### document intelligence pdf password workaround

## Why it happens
Document Intelligence's document parser has no decryption step and the API surface exposes no password field, so any encrypted PDF fails validation before analysis starts. Viewers prompt for passwords interactively; a headless API cannot.

## Edge cases
- User password vs owner password - either unlocks for reading, but some files restrict even the owner - verify the copy opens fully.
- Do not brute-force passwords; that is the document owner's call, not a troubleshooting step.
- DRM-protected or rights-managed PDFs may decrypt yet still fail on restricted content streams.
- Automating decryption is only okay with the owner's consent and a logged chain of custody.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NSinkNMLDNkG0mwWfx6yzQ