[BUG] CVP Passport migration regresses verified IDV records to denied

Preflight Checklist

• [x] I searched existing issues. The reports linked below describe related post-migration symptoms, but none documents the same verification ID changing from VERIFIED to DENIED.
• [x] This is a single bug report: incorrect CVP state migration/reconciliation in the Verification Portal / Passport backend.
• [ ] Latest Claude Code version. This is a server-side Passport state bug observed with Claude Code 2.1.258; the current release is 2.1.259.

What's Wrong?

A previously approved Cyber Verification Program (CVP) organization was migrated into Anthropic's new Verification Portal / Passport system. Since that migration, the organization has experienced inconsistent CVP state transitions and loss of its prior approval.

The strongest evidence is that the same identity-verification record was initially returned as successfully verified:

{
  "verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
  "verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
  "programSlugs": ["cvp"],
  "state": "PORTAL_VERIFICATION_STATE_VERIFIED",
  "validUntil": "2027-02-04T00:00:00Z"
}

The exact same verificationId later changed to:

{
  "verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
  "verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
  "programSlugs": ["cvp"],
  "state": "PORTAL_VERIFICATION_STATE_DENIED",
  "completedAt": "2026-08-31T20:13:01.987176Z"
}

The overall CVP application now returns:

{
  "applicationStatus": "PROGRAM_APPLICATION_STATUS_DENIED"
}

The same response also reports the use-case verification as incomplete rather than denied:

{
  "verificationType": "VERIFICATION_TYPE_USECASE_FORM_CYBER",
  "programSlugs": ["cvp"],
  "state": "PORTAL_VERIFICATION_STATE_ACTION_REQUIRED"
}

The resulting state is internally inconsistent:

• The same verification ID was previously VERIFIED with a future validity date of February 4, 2027.
• No new identity-verification attempt was initiated.
• The same record later became DENIED without an invalidation reason or remediation path.
• The use-case verification is ACTION_REQUIRED, not DENIED, while the application itself is already terminally DENIED.
• The organization was approved for CVP before the new Verification Portal workflow, but that prior approval was not retained or reconciled.

This appears to be part of a broader post-migration failure mode affecting previously approved CVP organizations. Potentially related user-visible reports include:

• #86867: approved CVP status unexpectedly changed to In review
• #89089: prior approval lost after the organization/portal migration and stuck In review
• #90316: prior CVP approval no longer recognized for an organization
• #87803: approved account reported as requiring CVP application
• #91566: active CVP status not honored by safeguards

Those reports describe downstream status/access symptoms. This report adds direct backend evidence of a same-object state regression in the Passport workflow.

Affected organization UUID:

22d47750-f24c-4b0d-bbc7-5f7d534bea39

Relevant backend service:

anthropic.passport.api.v1alpha.PassportVerificationPortalService

Relevant methods observed:

GetPortalPassport
ListPrograms
PreviewProgramApplication

What Should Happen?

A CVP identity-verification record that has already been successfully verified and has a future validUntil date should not silently transition from PORTAL_VERIFICATION_STATE_VERIFIED to PORTAL_VERIFICATION_STATE_DENIED without a new verification attempt, an explicit invalidation reason, or a remediation/appeal path.

If the record was intentionally revoked, the portal should expose a clear reason and provide a supported way to resolve or appeal the decision.

Previously approved CVP organizations migrated into the new Passport system should retain or correctly reconcile their prior CVP approval state.

Error Messages/Logs

ListPrograms currently returns:

{
  "programs": [
    {
      "program": {
        "slug": "cvp",
        "displayName": "Cyber Verification Program",
        "description": "Relaxed cyber safeguards for verified security researchers.",
        "presentation": {
          "unlocks": [
            "Basic Pentesting, Red Teaming, Bug Bounty use cases"
          ],
          "policyVersion": "1.0",
          "reviewSlaDays": 2
        }
      },
      "applicationStatus": "PROGRAM_APPLICATION_STATUS_DENIED"
    }
  ]
}

PreviewProgramApplication currently returns:

{
  "unmetVerifications": [
    {
      "verificationType": "VERIFICATION_TYPE_USECASE_FORM_CYBER",
      "programSlugs": ["cvp"],
      "state": "PORTAL_VERIFICATION_STATE_ACTION_REQUIRED"
    },
    {
      "verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
      "verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
      "programSlugs": ["cvp"],
      "state": "PORTAL_VERIFICATION_STATE_DENIED",
      "completedAt": "2026-08-31T20:13:01.987176Z"
    }
  ],
  "applicationStatus": "PROGRAM_APPLICATION_STATUS_DENIED"
}

Earlier capture of the same verification ID:

{
  "verificationType": "VERIFICATION_TYPE_TAF_CYBER_IDV",
  "verificationId": "fd19fc9e-3d46-80b4-8000-0313aeed4530",
  "programSlugs": ["cvp"],
  "state": "PORTAL_VERIFICATION_STATE_VERIFIED",
  "validUntil": "2027-02-04T00:00:00Z"
}

Steps to Reproduce

1. Use an organization that was previously approved for CVP and later migrated into the new Verification Portal / Passport workflow.
2. Complete the new cyber identity-verification process.
3. Observe the CVP verification state through the Verification Portal backend. In this case, the IDV record was initially returned as PORTAL_VERIFICATION_STATE_VERIFIED with validUntil: 2027-02-04T00:00:00Z.
4. Wait for the CVP application review state to change.
5. Query or open the CVP program page again so the portal calls PassportVerificationPortalService/PreviewProgramApplication.
6. Observe that the exact same verificationId is now returned as PORTAL_VERIFICATION_STATE_DENIED despite no new identity-verification attempt.
7. Observe that the overall application becomes PROGRAM_APPLICATION_STATUS_DENIED.
8. Observe that VERIFICATION_TYPE_USECASE_FORM_CYBER remains PORTAL_VERIFICATION_STATE_ACTION_REQUIRED rather than denied.

The regression is:

same verificationId

VERIFIED
validUntil = 2027-02-04

        ↓

DENIED
completedAt = 2026-08-31

Claude Model

Not sure / Multiple models; the defect is in the account-level Passport backend.

Is this a regression?

Yes. The organization was previously approved, and the same IDV record was previously VERIFIED.

Last Working Version

Not version-specific; the verified state existed before the Passport state transition.

Claude Code Version

2.1.258 (current repository release at filing time: 2.1.259)

Platform

Other: Anthropic Verification Portal / Passport backend

Operating System

macOS

Terminal/Shell

Other: zsh

Additional Information

The exact verification ID and organization UUID are included so Anthropic can trace the backend state transition and migration history. The portal currently exposes no invalidation reason, remediation flow, or appeal path, and support has not provided an effective resolution.