Start with the use case: enterprise accounts are for internal staff only
The Apple Developer Enterprise Program exists to distribute in-house apps to an organization's own employees, plus personnel the terms allow. It is not for the public, customers, or external testers, and it cannot publish to the App Store. Many people search for an enterprise account because they want to skip review for outside installs, which is exactly what the terms prohibit. The penalty is not one removed app. The distribution certificate gets revoked, and every app signed with it stops launching on every installed device. If your audience includes outside users, stop here and look at other options.
The entity bar is higher than for a standard company account
The enterprise program accepts legal entities only, never individuals. Enrollment typically needs a D-U-N-S number, a website and domain email that match the entity, and a person with authority to sign for the company. Apple also sets a minimum organization size and runs extra verification. The exact threshold and process are whatever Apple's enrollment page says at the time. In practice an enterprise account is not an ordinary order-and-use asset: whether the paperwork passes depends on the entity itself, not on who handles it.
Who the entity is determines whether you can use it legitimately
Rights and obligations in the agreement attach to the legal entity behind the account. If that entity is another company and you distribute your own company's apps to your own employees, those employees are not part of the licensed organization, and the terms no longer cover you. Check three things before ordering: whether the entity shown in the portal has a real affiliation or employment relationship with the party using it; whether the Account Holder and Agent can be changed through Apple's own process; and whether the agreement must be re-accepted by a new authorized person afterward. If any answer is unclear, do not treat the account as something that hands over cleanly.
Portal fields to verify one by one
If you can see the portal, confirm these items: the plan type on the Membership page is Enterprise, along with the Team ID; the entity name, D-U-N-S number and registered address match; who the Account Holder and Agent are and how to reach them; the membership expiry date and renewal status; under Certificates, Identifiers & Profiles, how many distribution certificates exist, when they expire, and whether any were revoked; which Bundle IDs the provisioning profiles cover; and who controls the email and two-factor phone number on the Apple ID. If the login email and verification phone are not in your hands, every later certificate task can get stuck.
Beyond distribution: certificate lifetime and device management keep it running
Enterprise distribution relies on signing certificates and provisioning profiles, and both expire. When a certificate lapses or is revoked, installed apps stop launching, so someone must renew it before expiry and re-sign builds. For staff devices you usually also need MDM to manage installs, updates and offboarding. Ask when the current certificates expire, whether renewal requires a rebuild, who holds the private key and the exported p12 file, and how access is revoked when an employee leaves. If these duties are not written down at handover, the account quickly becomes an operations gap.
Signs you should stop or switch plans
Do not proceed if your audience includes customers, outside testers or the public; if your company falls below Apple's size requirement and you plan to borrow another entity; if the seller cannot show the plan type, entity and certificate status in the portal; or if the account has a revoked-certificate history nobody can explain. Most of these needs have a better fit: TestFlight for testing, Ad Hoc for a small set of registered devices, custom apps through Apple Business Manager for specific organizations, and a standard company developer account for public release. Matching account type to purpose matters more than how old the account is.