In a previous post we looked at where ISE keeps endpoint attributes — the configuration database, the per-PSN endpoint cache, and the Context Visibility store — and why the location an attribute lands in decides what it costs you. That post begged a question: if writing an attribute to the configuration database is the expensive path, and every write there triggers replication across the deployment, then which attributes actually take that path? ISE collects a lot per endpoint. It clearly isn't replicating all of it.
It isn't. ISE sorts the attributes it collects into a handful of classes, and the class decides the treatment: whether the attribute is even allowed into profiling, whether it gets written to the database and replicated, and whether changing it forces ISE to reclassify the endpoint. Get a feel for these four classes and a lot of profiling behavior — including the performance kind — stops being a surprise.
The four classes are:
Picture two gates, not four bins.
The first gate is the whitelist: is this attribute allowed in for profiling at all? With the Endpoint Attribute Filter enabled — which Cisco recommends for production — anything not on the whitelist is dropped the instant it's collected. That's the line between whitelisted and other. On the list, ISE keeps it and uses it; off the list, it's gone, and it never costs you a thing.
The significant attributes live inside that whitelisted set. They're the subset important enough that ISE doesn't just use them for profiling but writes them to the configuration database and replicates them to every node. So "significant" isn't an alternative to "whitelisted" — it's the expensive core within it. A whitelisted attribute that isn't significant gets used by the profiler and sits in the PSN's endpoint cache without triggering deployment-wide replication. A significant one does both.
Custom attributes are a separate lane onto the whitelist. Define one and reference it in a profiling condition, and it gets added to the whitelist like any other policy-driven attribute — but only if you've turned the feature on. Leave it off, and the profiler ignores it regardless.
One terminology note, because it trips people up. Cisco's admin guide often uses "significant" loosely to mean everything the filter keeps — effectively treating significant and whitelisted as the same set. The session draws the finer line we're using here: significant as the always-replicated core, whitelisted as the broader gate around it. Same machinery either way; just know that "significant" shows up at two different scopes depending on which document you're reading.
Some attributes are important enough that ISE wants them identical on every node, all the time. These are the significant attributes — persisted to the configuration database and replicated across the deployment.
The list is what you'd expect once you think about what has to be consistent everywhere:
These drive authorization decisions and have to survive a node reload, so ISE treats them as data of record rather than transient cache.
That consistency is the upside. The cost is that every change to a significant attribute is a database write, and every database write is replicated outward. One endpoint flipping profile once is nothing. The problem is scale and churn — and this is the part worth remembering: as the number of endpoints grows, frequent significant-attribute changes can make the profiler the single biggest contributor to replication traffic in your whole deployment. A profiling decision, made thousands of times a minute across a large fleet, becomes a deployment-wide load problem. That's the mechanism behind a lot of the "why is replication unhappy" cases that trace back to profiling.
A few attributes aren't significant in their own right but still trigger this database-persistence behavior — certain WiFi Device Analytics, MDM, and AI Endpoint Analytics fields among them. The practical takeaway is the same either way: anything that writes to the database is something you want changing as little as necessary.
The whitelist is the gate the significant attributes live behind, and it's worth understanding on its own because it's your main lever for keeping profiling lean.
When the Endpoint Attribute Filter is on, any attribute not on the whitelist is dropped at the moment of collection — it never enters profiling, never gets stored, never replicates. What's on the list isn't arbitrary, and you don't hand-curate it. ISE whitelists the attributes needed for the default Cisco-provided profiling policies, plus what's required for critical RADIUS operations, BYOD, and web authentication, and it updates the list automatically as the profiler feed changes or as you add your own conditions.
The reason this matters is the mirror image of the significant-attribute problem. Significant attributes are expensive data you can't avoid carrying. The whitelist is the mechanism that discards everything you don't need before it can cost you anything. Leave the filter off and ISE collects and carries attributes no policy will ever use — pure overhead, and more replication than you need. Turning it on is one of the simplest ways to keep a deployment lean, which is exactly why it's a production recommendation.
Custom attributes are ones you define yourself — fields outside ISE's built-in set, populated through the admin UI, the REST API, or the pxGrid probe. They're useful when you're classifying assets on criteria ISE doesn't ship with.
They're gated by their own switch — "Custom Attribute for Profiling Enforcement" — and it's off by default. With it off, the profiler ignores custom-attribute conditions entirely, even if the attribute is populated on the endpoint. Turn it on and ISE acts on those attributes, which means it triggers an automatic reprofiling action whenever a custom attribute is modified. Update custom attributes at a high rate with enforcement on, and that reprofiling churn lands right back on the performance concerns from the significant-attribute section.
The guidance is blunt and worth repeating: don't enable this unless you specifically need it. A custom attribute that's defined, enabled, and actually used in a profiling condition gets added to the whitelist and does its job. One turned on speculatively and then updated often is a self-inflicted performance problem.
The last type is the simplest. Attributes that aren't significant, aren't on the whitelist, and aren't enabled custom attributes are, for profiling purposes, noise. With the filter on they're dropped at collection and never drive classification. There's nothing to manage here — it's just what's left once the gates have taken what they need.
The single idea underneath all of this is that an attribute's type is really a statement about its cost. The whitelist decides what's allowed in versus discarded for free. Significant attributes are the subset that buys consistency and pays for it in replication. Custom attributes are opt-in cost — useful when you mean it, wasteful when you don't.
That framing turns a couple of vague best practices into something you can reason about. Keep the Endpoint Attribute Filter on, because it's the gate dropping attributes you'd otherwise pay to carry. Leave custom-attribute enforcement off unless a policy genuinely needs one, because enabling it adds reprofiling churn. And when replication or load looks wrong and the trail leads to profiling, the question to ask is which significant attributes are changing, how often, and why — because that churn is the most common way a profiling choice turns into a deployment-wide problem.