Enterprise OIDs (1.3.6.1.4.1): Vendor Numbers Explained

By the SNMP Monitoring team · Reviewed July 2026

Standard MIBs don’t cover every chassis LED and proprietary counter. Vendors hang that stuff under the enterprise branch: 1.3.6.1.4.1, then a Private Enterprise Number (PEN), then their tree.

Your goals on this page: decode 1.3.6.1.4.1.x…, look up who x is, and know how orgs get a PEN from IANA (it’s free—don’t invent one). Parent: OID. Tree context: OID tree.

What is an enterprise OID / PEN

An enterprise OID is any object under 1.3.6.1.4.1.<PEN>.….

A Private Enterprise Number (PEN) is an integer assigned by IANA identifying an organization in that branch. Registration is free. The PEN is not a secret API key—it’s a public namespace allocation. The objects under it are defined in the vendor’s MIBs and firmware.

Inventing a PEN “because it looked free” is how you collide with a real org and confuse every tool on earth. Don’t. Apply, or use an existing assignment your company already owns.

The 1.3.6.1.4.1 branch

Path reminder:

• 1.3.6.1 — internet
• 1.3.6.1.4 — private
• 1.3.6.1.4.1 — enterprises

Under enterprises, each child is a PEN root. Vendors structure modules however they like after that—some neat, some archaeology.

Standard mib-2 stays at 1.3.6.1.2.1. Different branch, different politics. See OID tree.

Well-known vendor PENs

Commonly cited numbers (confirm against the IANA enterprise-numbers registry before you tattoo them into legal docs—assignments can be checked at iana.org). Values listed in our brief / widely published:

If a PEN isn’t in this table, look it up—don’t guess. Device guides: Cisco, MikroTik.

How to look up a PEN

1. IANA enterprise-numbers registry — authoritative who-owns-what for the integer.
2. Vendor MIB / docs — what objects exist under their root.
3. MIB browser — navigate once modules loaded (MIB browser).
4. Walk the device — firmware truth:

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.4.1.8072

NET-SNMP-MIB::netSnmpAgentOIDs.10 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
(…further objects if implemented and allowed by the view…)

Empty walk ≠ wrong PEN necessarily—views, unimplemented branches, or wrong device. Widen carefully; don’t walk all of 1.3.6.1.4.1 on production.

sysObjectID often points into an enterprise tree and hints which vendor stack you’re on—still verify.

Registering your own PEN

If you build products that need a private MIB space:

1. Go to IANA’s Private Enterprise Number application process (public web form / instructions on iana.org).
2. Provide organization details they request.
3. Wait for assignment—free, not a purchase of “SNMP rights.”
4. Document the PEN internally like a production identifier.
5. Design your MIB under 1.3.6.1.4.1.<yourPEN> with normal SMI discipline.
6. Publish modules to customers; don’t make them reverse-engineer walks only.

Numbered ops follow-up after you get a PEN:

1. Reserve sub-branches (product lines) on paper before shipping three conflicting trees
2. Version MIBs
3. Never reuse another org’s PEN “temporarily”

Using enterprise OIDs in custom monitoring

Patterns:

• Prefer standard OIDs when they exist (portable templates).
• Use enterprise OIDs for vendor-specific health (optics, ASIC, proprietary CPU).
• Isolate enterprise checks per device class in the NMS.
• Custom app metrics: implement under your PEN or via AgentX/extend—see custom OID.

Device-oriented entry points: Cisco, MikroTik, broader devices.

Allowlists: open the specific enterprise prefixes you need, not 1.3.6.1.4.1 whole-cloth, unless you enjoy oversharing.

Hallucination warning (yes, really)

The #1 content failure on this topic is inventing PENs or leaf numbers. If you don’t have IANA or a vendor MIB in front of you, write “vendor enterprise branch” and walk the box. Numeric fiction in a dashboard is worse than a missing graph.

Field notes

• Same metric name, different enterprise OIDs across vendors — templates must fork.
• OEM rebrands may keep parent PEN or slap their own—walk sysObjectID.
• UCD 2021 objects still show up on Linux net-snmp agents for load/disk style data—even when you’re not “a UCD shop.”
• Mergers: PEN ownership on paper vs what firmware still emits can lag.

Mini workflow for a new vendor widget

1. Identify PEN (IANA + sysObjectID + docs).
2. Fetch official MIB package.
3. Load in browser; note candidate OIDs.
4. snmpwalk those prefixes on lab hardware.
5. Only then productionize.

Glossary: glossary. Standard contrast: standard MIBs.

PEN hygiene for orgs that ship gear

If your company acquires another firm, inventory both PENs and what firmware still emits. Customers will keep walking the old root for years. Document dual support windows. If you only make internal tools, you might not need a public PEN at all—use standard objects or a private lab tree that never leaves your network—but the moment a customer must load your MIB, get a real IANA number.

Also: don’t put secrets in enterprise OIDs. They’re not encrypted by virtue of being “private.” Private means namespace private, not confidentiality. Treat enterprise walks like any other SNMP data: RO credentials, views, and source ACLs still apply.

Frequently asked questions

What is 1.3.6.1.4.1?

The private enterprises branch of the OID tree—root for vendor/organization PENs and their enterprise MIBs.

What is a private enterprise number?

A PEN is an integer assigned by IANA identifying an organization under 1.3.6.1.4.1. Registration is free.

How do I get an enterprise OID?

Apply to IANA for a PEN, then define objects under 1.3.6.1.4.1.<yourPEN> in your MIB modules. You don’t buy a random number off a blog.

Where do I find a vendor's OID?

IANA registry for the PEN; vendor MIB/docs for leaves; confirm with snmpwalk / MIB browser on real gear.

Key takeaways

• Enterprise root: 1.3.6.1.4.1.
• Next arc = PEN (IANA, free)—never invent.
• Well-known PENs in the table—recheck IANA when accuracy matters.
• Monitor: standard first, enterprise for gaps; allowlist tight prefixes.
• Next: OID, tree, custom OID.