Skip to main content
This guide is for existing customers on the legacy project-based model. If you’re new to Infisical Certificate Manager, start with Getting Started.

​
What Changed

Certificate Manager now operates as a single project per organization. Certificate Authorities, policies, and profiles live at the product level — shared across your organization, managed by admins. Applications are where teams work. Each Application represents a service or workload (e.g., payments-api, mobile-backend) and has its own members, certificates, alerts, syncs, and approval policies. 
Organization
└── Certificate Manager
    ├── Certificate Authorities    ← shared, admin-managed
    ├── Certificate Policies       ← shared, admin-managed
    ├── Certificate Profiles       ← shared, admin-managed
    └── Applications
        ├── payments-api
        │   ├── Members, Enrollment Methods
        │   └── Certificates, Alerts, Syncs
        └── mobile-backend
            └── ...
Before (Projects)After (Applications)
Everything in one projectShared infrastructure + scoped Applications
Project-level access (see everything)Application-level access (see only your service)
Enrollment baked into profilesEnrollment configured per Application
Custom roles + conditions for scopingSimple roles: Admin, Operator, Auditor
Alerts/syncs at project levelAlerts/syncs scoped to each Application
What this gets you:
  • Shared CAs — Define Certificate Authorities once, use them across your entire organization
  • Simpler access control — No more custom roles or attribute conditions. Add members to an Application, pick a role, done.
  • Team autonomy — Each team manages their own Application
  • Clear ownership — When someone asks “who manages certificates for this service?” the answer is in the Application’s member list
For details on the new access control model, see Access Control.

​
Before You Start

Your existing setup keeps working. Certificates will keep renewing, alerts will keep firing, syncs will keep running. You’re not forced to migrate immediately. If your organization has multiple Certificate Manager projects, all of them remain accessible. The designated active project loads by default, and legacy projects can be opened directly to be wound down on your own timeline.
Applications are scoped to the active project. Within an organization that contains multiple Certificate Manager projects, the Applications experience is available exclusively on the project designated as active under Organization Settings → Products → Certificate Manager. Applications are not supported in legacy projects.
Plan your migration before starting:
  1. Inventory your current setup — Document your CAs, profiles, alerts, syncs, and approval policies across all projects
  2. Map services to Applications — Decide how you’ll organize your Applications (e.g., one per service, one per team)
  3. Identify who owns what — Figure out which team members should have access to each Application and what role they need

​
Migration Steps

Have only one project? Skip to Set up Applications — you don’t need to consolidate anything.

​
If you have multiple existing projects

If you have CAs, policies, or profiles spread across multiple existing projects, consolidate them first:
1

Designate the active project

Navigate to Organization Settings → Products → Certificate Manager. In the projects table, mark the project you intend to consolidate into as Active. All members and integrations across the organization will subsequently resolve to this project. Designating an active project also unlocks Applications. Until one is selected (in organizations with multiple Certificate Manager projects), Applications cannot be created or administered.
2

Export entities from legacy projects

From the same projects table, locate a legacy project, open its actions menu, and select Export to active project.The export copies the following resources into the active project:
  • Internal and private Certificate Authorities, including the full chain and key material (re-encrypted under the active project’s KMS key)
  • Certificate Policies
  • Certificate Profiles that reference a self-signed or internal CA
External CAs and any profiles dependent on them are excluded from the export. Alerts, certificate syncs, and approval policies are not exported and must be reconfigured inside Applications later.
Resources are copied rather than moved, originals remain in the legacy project. When a CA, policy, or profile name collides with an existing resource in the active project, the exported copy is renamed automatically. Once the export completes, treat the legacy project as read-only and direct new work to the active project.
Repeat for each remaining legacy project.

​
Set up Applications

Once you’ve consolidated your projects (or if you only have one), go to your active project to set up Applications. All the steps below happen inside the active project.
1

Create your Applications

Applications represent services or workloads that need certificates (e.g., payments-api, mobile-backend).
  1. Go to Certificate Manager → Applications
  2. Click Create Application
  3. Name it after the service it represents
Create one Application for each service. Think about ownership: who is responsible for certificates for this service?
2

Configure enrollment methods

For each Application, attach profiles and configure how certificates will be requested:
  1. Go to the Application’s Settings tab
  2. Find the Certificate Profiles section
  3. Attach the profiles this Application needs
  4. Configure enrollment methods (API, ACME, EST, SCEP) for each profile
One profile can serve multiple Applications with different enrollment methods.
3

Set up alerts, syncs, and approval policies

For each Application, recreate your operational configuration:Alerts: Go to Settings → Alerting and create alerts for expiration, issuance, renewal, or revocation.Syncs: Go to the Certificate Syncs tab and configure where certificates should be pushed.Approval policies: Go to Settings → Approval Policies and configure approval requirements for each profile.
Legacy alerts, syncs, and approval policies at the project level will keep working. You can modify or delete them, but new ones must be created inside Applications.
4

Add team members

For each Application:
  1. Go to the Members tab
  2. Add team members and assign roles:
    • Admin — Configure enrollment, syncs, alerts, approvals. Manage members.
    • Operator — Issue, renew, revoke certificates
    • Auditor — View-only access
Members also need the Product Member role at the product level to access Applications they’re assigned to.
5

Update your issuance clients

Enrollment URLs now include both Application and Profile. Update your:
  • ACME clients (Certbot, cert-manager, etc.)
  • Infisical Agent — Update to reference application-name and profile-name
  • EST/SCEP clients
  • Terraform — Update infisical_pki_* resources
  • API integrations
Legacy enrollment endpoints continue to work, but new issuance should use the Application-based endpoints.
6

Transition your team

Once Applications are set up:
  1. Communicate the change to your team
  2. Point them to their assigned Applications
  3. Stop creating new resources in legacy projects
  4. All new work happens in the active project, inside Applications

​
FAQ

Yes. Legacy profiles with enrollment methods configured will keep issuing certificates. You don’t need to migrate everything at once.
Yes. The project selector lets you access all your projects. You’re not forced to migrate immediately.
No. Existing certificates remain valid. The migration is about how you organize and manage certificates going forward.
The export operation produces an independent copy of the CA in the active project. Certificates issued and revocations performed after the export are not synchronized between the original and the copy. The active project should be treated as the system of record going forward.
Your existing setup keeps working, but new alerts, syncs, and approval policies must be created inside Applications. Legacy projects remain accessible but won’t receive new features.
A profile defines what a certificate looks like: one CA, one policy, one set of constraints. A service often needs multiple certificate types. Keeping profiles at the product level lets admins define them once and let multiple Applications consume them, each with their own enrollment methods and access control.
Applications live on your organization’s active Certificate Manager project. Designate one under Organization Settings → Products → Certificate Manager and Applications will appear there. Legacy projects remain fully accessible for everything else.

​
Need Help?

If you have questions about migration, contact support@infisical.com.